smallwiki

smallwiki@list.inf.unibe.ch

2312 discussions

MNU PREyeInspector>>elements for PRDocument with EyeTreeInspector

by Ben Coman

I was looking at PRAnnotatedParagraphTest>>testParseBasic and Inspected the result of the following... | wiki text tree | wiki := '@@foo bar zork'. text := 'bar zork'. tree := PRDocument new add: (PRAnnotatedParagraph new annotation: 'foo'; add: (PRText content: 'bar zork'); yourself); yourself. The Inspector comes up okay using PREyeItemInspector to show PRDocument. However when I change to EyeTreeInspector I get the error "MNU: PREyeItemInspector>>elements" I tried digging into this but its beyond my current understanding. In particular, PREyeInspector seems to have two potential sources of elements: * ivar /tree/ holding a TreeModel that might return roots and/or children * ivar /object/ holding a NewValueHolder holding a PRDocument that might return its children. Is there somewhere I should log a case for Pillar? cheers -ben

10 years, 7 months

Pillar annotations for Latex

by Ben Coman

The Pillar documentation [1] says... "An annotated paragraph starts a line with @@ followed by either todo or note. For example, @@note this is a note annotation. generates Note: this is a note annotation. And, @@todo this is a todo annotation generates a todo annotation that is not visible in the output." However this does not work when rendering to LaTex. * The notes do not start with "Note:" * The todos are visible This seemed to be handled by... PRMarkdownWriter>>visitAnnotatedParagraph: anAnnotatedParagraph "Pier seams to lack consistensy here ..." needsABreak ifTrue: [ canvas addInvisibleSeparator ]. anAnnotatedParagraph annotation asLowercase = 'todo' ifTrue: [ ^ self visitCommentedLine: anAnnotatedParagraph ]. self nest: [ :brush | brush name: '' with: [ :nestedStream | self writeRawDuring: [ nestedStream << 'Note: '. nestedStream << anAnnotatedParagraph text trimBoth ] ] ]. needsABreak := true. but that there is no equivalent PRLaTexWriter>>visitAnnotatedParagraph: and the following is used by default... PRVisitor>>visitAnnotatedParagraph: aDocument self visitParagraph: aDocument In seeking to fix this for LaTex I found... * /needsABreak/ is an ivar of PRMarkdown and I guess not applicable to LaTex * #nest: and the /nest/ ivar it references belong to PRMarkdown, and I'm not sure of their purpose. So I cut those out, which left the following... PRLaTexWriter>>visitAnnotatedParagraph anAnnotatedParagraph annotation asLowercase = 'todo' ifTrue: [ ^ self visitCommentedLine: anAnnotatedParagraph ]. self writeRawDuring: [ nestedStream << 'Note: '. nestedStream << anAnnotatedParagraph text trimBoth ]. ...which works well enough for the usage I see so far in PharoLaserGameTutorial. [2] Now is there any important function missing, or is there a better way to do this? I also want add an annotation type, which I'll describe in a following post. cheers -ben [1] https://github.com/pillar-markup/pillar-documentation [2] https://github.com/bencoman/PharoLaserGameTutorial

10 years, 7 months

Magritte versions

by Diego Lont

Hi all, We would like to have more communication about the Magritte configuration. We will start by describing the current state, as far as we know it. The current released version of Magritte is 3.1.3. This versions contains the latest changes and is a release version, so should not be changed. Please use #release3.1 in referring to this version, to allow for minor updates and bug fixes to be automatically integrated. The #release3.0 is also maintained, as this refers to #release3.0 of Seaside. And as long as #release3.1 of Seaside is not released on Gemstone, I will maintain this version. There is also versions 3.2. We do not know why this version is created. It uses a duplicate baseline (only the Grease version differs), and no big changes for Magritte are planned (to my knowledge). So we propose to remove this version. If you want this version to be kept, please reply this mail with a reason. Version 3.2 is outdated, but it implies to be more recent than 3.1.3. For the time being I will only remove the 3.2-baseline, as it is duplicate. If I do not receive a mail saying 3.2 should be kept, I will remove this version beginning of June. For development I will create a version 3.1.4. I will also point #development to this version. Discussion on Magritte List. Cheers, Stephan and Diego

10 years, 7 months

Configuration management Magritte and Pier

by Diego Lont

Hi all, I notice that for Grease and Seaside changes in the versions are always discussed on the Seaside list. Now maybe not all changes should be discussed, but for the major projects, like Magritte and Pier, I would like to have at least an announcement if a change is made in the configuration. To be more exact, I have no idea why version 3.2 was created in Magritte. I cannot find any mail on the list about this version. Secondly I would like people to use release versions of Grease, Seaside, Magritte and Pier as much as possible. I have introduced releases for Grease, Seaside, Magritte and Pier to all have a #’release’. These release “remove” the last index. So for Seaside the current released version is: 3.1.0.2. This means there is a #release3.1, referring to ‘3.1.0.2' and a #release3.0 referring to ‘3.0.12’. When there is an important bug fix, version 3.1.0.3 will be created with this fix, and release3.1 will point to that version. And when 3.1.1 is released, #release3.1 will point to this version. To be completely consistent, there should be a #release3.1.0 as well (referring to 3.1.0.2). There is also a #release3, that is the latest recommended release. As this is different for squeakCommon and gemstone at the moment, this is a special case for Seaside, but normally it would simply point to release3.1. It might be a good idea to introduce #releases to more configurations. Discussion on the Magritte list. Cheers, Diego

10 years, 7 months

Re: callbackMarker not found in Seaside stack

by Otto Behrens

Hi, A weirdness we had in our system was that the accessor called by a Magritte description raised an Error. This code is called in a callback of a button: [ aComponent call: (MatchInvestmentPage new instruction: self; yourself). aComponent reset ] on: Error do: [ :err | aComponent inform: err messageText. aComponent answer ] It tries to handle the error raised by "aComponent reset". The MatchInvestmentPage component changes the state of the model of aComponent (a magritte container component). The "aComponent reset" causes a magritte MADescription (displaying a fairly simple amount field) to call an accessor on the model, which raises the error. We now removed this error handler and check for the error condition elsewhere. A broader question here is whether magritte descriptions should handle exceptions when reading from the model (Object >> readUsing: which calls #read: on). Our understanding is that reading via accessors (MAAccessor descendants) should not handle exceptions and a fallback (outer) handler should handle it, because this is really unexpected. Is this right? Does anyone know what the best way is to handle this situation? Does it make sense to handle exceptions at the description level and display a message to the user (on the field itself)? Not sure that it does, but perhaps someone have better ideas here. Thanks Otto PS. Does anyone have suggestions on nicer dialogs (the inform: call here) that perhaps uses JQuery or another mechanism? On Wed, May 21, 2014 at 10:45 AM, Otto Behrens <otto(a)finworks.biz> wrote: > Hi, > > Pardon the delay on the response here. We decided to simplify the flow of > screens here to avoid the problem, in the light of a possibly complex way > that we're implementing the requirement and a pressing client. > > But we'd like to explore this a bit more to see if we can find this > because it may be a problem elsewhere in our system or for someone else. > > Firstly, we are using https://github.com/glassdb/Seaside30. The comment > says Seaside 3.0.7.1. I don't know how to figure out what version of > seaside this is besides trusting the comment. Looking at logs when loading > from scratch does not tell me much. How will I go about figuring out the > version that we've got loaded? From Johan's recent mail, I take it that > https://github.com/glassdb/Seaside31 could be good to upgrade to. > > To get back to the problem, I think the continuation was created with > > Scriptaculous >> lightbox: aComponent > ^ self wait: [ :cc | > self > show: aComponent > onAnswer: cc > delegation: (SULightbox new > delegate: aComponent; > yourself). > WARenderNotification signal ] > > Yes, we still have some Scriptaculous bits to get rid of, so if this is > the problem, the time is now. > > What do you think? Is this it? > > Thanks > Otto > > > On Tue, May 20, 2014 at 3:05 AM, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> Otto, >> >> Another possibility ... although I don't know if this kind of thing would >> be possible but here goes nothing ... >> >> If the callback that we're looking at with the broken stack was created >> during WADispatchCallback>>evaluateWithArgument: or >> WAMultiSelectTag>>triggerCallback and inform: answer was run in >> WACallbackRegistry>>handle:, then the call back would have been created >> with one less frame on the stack (no do: frame) ... and that would provide >> us with a nice off by one error ... >> >> some logging in the methods WADispatchCallback>>evaluateWithArgument: and >> WAMultiSelectTag>>triggerCallback, where you record the oop of >> theWACallback instance and logging in WACallbackRegistry>>handle: >> recording the oops of WACallbacks run should rule this hare-brained idea >> out or rule it right into play:) ... >> >> Dale >> >> >> On Mon, May 19, 2014 at 5:41 PM, Dale Henrichs < >> dale.henrichs(a)gemtalksystems.com> wrote: >> >>> Otto, >>> >>> I haven't been able to reproduce the bad error yet and I think that the >>> corruption is being caused by the previous callback in the set ... the >>> stack is corrupt at the point you try to create the continuation for the >>> inform: in the validation block ... >>> >>> setting breakpoints in the WACallback>>evaluateWithFieldValues: will >>> catch the first callback in this sequence .. check to see if the stack >>> looks corrupt in the first call, then continue and see if the stack looks >>> corrupt before executing the code for the second callback ... if we can >>> isolate the transition from good stack to bad stack, we'll be on our way to >>> a solution... >>> >>> I'm a bit suspicious of Magritte in the mix and the#reset message ... if >>> the structure of objects have been changed between the time the >>> continuation is created and the time it gets used, there might be trouble >>> ... but I'm only grasping at straws at this point in time ... BTW, what >>> version of Seaside and Magritte are you using? >>> >>> If Pieter's case is simpler, we might be able to figure it out easier >>> ... I'd like to see the two addForm: methods:) Just in case something jumps >>> out at me... >>> >>> Dale >>> >>> >>> >>> >>> On Mon, May 19, 2014 at 2:48 PM, Dale Henrichs < >>> dale.henrichs(a)gemtalksystems.com> wrote: >>> >>>> Otto, >>>> >>>> Given an instance of WACallback, you can determine the source code of >>>> the method where the callback is defined by looking at the `block` instance >>>> variable og a WACallBack instance ... then in 3.1: >>>> >>>> block _method sourceString. "source" >>>> block _method inClass "class" >>>> block _method _lineDeltaForBlock "line number in source (ignoring >>>> selector)" >>>> >>>> This can be done from a debugger (topaz) when error occurs ... navigate >>>> up the stack to the WACallback>>evaluateWithFieldValues: frame... get the >>>> oop of the _method (use `display oops`) and then sued the `send` command to >>>> send the three different messages: >>>> >>>> send @34379893 sourceString >>>> >>>> ... still digging ... >>>> >>>> Dale >>>> >>>> >>>> >>>> On Mon, May 19, 2014 at 10:55 AM, Otto Behrens <otto(a)finworks.biz>wrote: >>>> >>>>> Thank you, Dale. I'm finally at home :) >>>>> >>>>> >>>>> On Monday, May 19, 2014, Dale Henrichs < >>>>> dale.henrichs(a)gemtalksystems.com> wrote: >>>>> >>>>>> Otto, >>>>>> >>>>>> Thanks! >>>>>> >>>>>> I'm finally in the office ) and will spend some time today getting >>>>>> myself grounded in continuations again ... then I should have a better idea >>>>>> how to proceed ... >>>>>> >>>>>> Dale >>>>>> >>>>>> >>>>>> On Mon, May 19, 2014 at 9:47 AM, Otto Behrens <otto(a)finworks.biz>wrote: >>>>>> >>>>>>> > perhaps capturing the stack at the point the continue is created >>>>>>> will give >>>>>>> > us clues ... >>>>>>> >>>>>>> Attached are some stacks that I hacked in by calling the following >>>>>>> method where we create them: >>>>>>> >>>>>>> WAPartialContinuation >> printStack >>>>>>> | stream | >>>>>>> stream := GsFile openWriteOnServer: '/tmp/stack_', self asOop >>>>>>> printString. >>>>>>> [ stream nextPutAll: partial printString ] ensure: [ stream close ] >>>>>>> >>>>>>> It does not tell me much at the moment. But perhaps you can see >>>>>>> something. Or perhaps you have a better printing method that I can >>>>>>> call? >>>>>>> >>>>>>> Thanks >>>>>>> Otto >>>>>>> >>>>>> >>>>>> >>>> >>> >> >

10 years, 7 months

Encoding problem

by Stephan Eggermont

We have an issue in default Pier with rendering/encoding. Did I miss setting encoding somewhere? If we enter in WAEncodingFunctionalTest the following three characters: ->ë the text input field removes the -. We noticed because the text area used to edit pier documents became unusable. Stephan

10 years, 7 months

Re: Weird behaviour when contents contain certain characters?

by Stephan Eggermont

Hi Sergi We have been able to confirm the behavior. Replacing a ë by a e solved it, so it looks like an encoding problem. Stephan

10 years, 7 months

Pier and Bootstrap together

by Diego Lont

Hi all, I have created my site using bootstrap and pier. For people who want to see: http://www.delware.nl/ If there are more people who want to use bootstrap in their pier-site, please let me know. Now I want to add this site on the pier website. Who manages this website? And can I be added as an admin here? Cheers, Diego

10 years, 7 months

Weird behaviour when contents contain certain characters?

by Sergi Reyner

When I input certain data as the contents of a page, and I later go to edit the page, I get all sorts of weird behaviour, like: - getting only the Title field - getting no fields - getting some html in the editor instead of the page contents I am not sure of what exactly is triggering the bug, the following text should do it: !Algunos hosts > !!Listado 1 > |!NOMBRE|!IP|!MAC|!UBICACIÓN| > |a|192.168.1.1{{{<br/>}}}192.168.2.1|12:34:56:78:90:12|here| > |b|192.168.1.2|12:34:56:78:90:12|there| > !!Listado 2 > |!NOMBRE|!IP|!MAC|!UBICACIÓN| > |c|192.168.1.3|12:34:56:78:90:12|here| > |d|192.168.1.4|12:34:56:78:90:12|here| > |e|192.168.1.5|12:34:56:78:90:12|here| > |f|192.168.1.6|12:34:56:78:90:12|there| Variations on it may produce different results. Cheers, Sergi

10 years, 7 months

Re: Pier 3

by Gareth Cox

Hi! I use Pier extensively. I use Pier3 on Pharo1.4 I have come across some of the bugs mentioned. I'd love to see Pier under more development, and I'd like to help (with what little time I have). KR Dusty > Hi all, > > Now that I am starting to use Pier, I notice several things: > 1. The current version of Pier has become a bit unstable. The bugs I have found so far are: > - The default installation no longer requires you to be logged in to change content. This is because the owner is no longer set by default. > - The default installation no longer allows you to select a template. > I do not know how much this has to do with the work Damien is doing, but the question arises: who are currently the core team of Pier? > > 2. The website of Pier is outdated. It still refers to Pier2, the repository of Lucas Renggli, some new add-ons are missing, and several links to examples are no longer working. > > 3. Also Pier itself could use some new input. I am thinking about a bootstrap packages, that adds a bootstrap template, and allows to add bootstrap components, like a jumbotron, to be added easily, without having to resort to ?verbatim?. And maybe there are other things that are missing too. > > I am willing to do some work, as I am now using Pier for my website, but I don?t think I can do it without help. > > Stephan and I already did some work on the code exporter, so has become more easy: > - to migrate a Pier site to the current version > - to develop Pier local, and deploy Pier remote. > We should probably add a screen cast and installation scripts, but then: who will put it on the Pier website? > > So who is using Pier also and wants to help get it up to date? > > Cheers, > Diego -- Gareth Cox IT Manager/Developer i nspired ! email: gareth(a)inspired.org <mailto:gareth@inspired.org> cell: +27 (0)78 374 9035

10 years, 7 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki