smallwiki May 2014

smallwiki@list.inf.unibe.ch

9 participants
13 discussions

by Damien Cassou

Hi, is there any photo gallery available for Pier? I mean a widget where I could upload pictures and they are rendered in a nice way. I started one 4 years ago but I abandoned it. Bye -- Damien Cassou http://damiencassou.seasidehosting.st

6 years, 6 months

[Pharo-users] [smallwiki] Pillar annotations for Latex

by Ben Coman

> Hi Ben, > > On Thu, May 22, 2014 at 6:09 PM, Ben Coman<btc(a)openinworld.com> wrote: > > Now is there any important function missing, or is there a better way to do > > this? > > thank you for your contribution. > > I would try to generate this instead: > > \begin{note} > foo bar baz > \end{note} > > This environment is meant for this. To output the \begin and \end parts, use > > canvas environment > > (look at the senders of #environment in the PRLaTeXWriter class for examples) > > To output the text, you can just write > > super visitAnnotatedParagraph: aParagraph > > > > I also want add an annotation type, which I'll describe in a following post. > > > I should we should think a bit how these should be handled. In the > meantime, you can just hack around :-). And please add unit tests. > > -- > Damien Cassou So I determined that the following works well... PRLaTeXWriter>>visitAnnotatedParagraph: anAnnotatedParagraph "Pier seams to lack consistency here ..." 'todo' = anAnnotatedParagraph annotation asLowercase ifTrue: [ ^ self visitCommentedLine: anAnnotatedParagraph ]. canvas environment name: 'note' ; with: [ super visitAnnotatedParagraph: anAnnotatedParagraph ]. to process Pillar markup... @@note Pay attention to the class definition for your new ""==BlankCellTest=="". It must be a subclass of the class ""==TestCase=="". This is easy to overlook. If you did it wrong already, no problem, just go back and correct it now and then save the code again. Within a class, methods are organised into "protocols" that are shown in the third browser pane from the left of Figure *testCellStateShouldBeOffEmpty*. We will group our "tests" inside a protocol of the same name. to produce this nice looking PDF showing the note indented with dividing lines... Now that was real easy to do!! Thanks for making Pillar accessible. I can't imagine making a similar change as easy in a Markdown processor in some other language. --------------- Next, in common.tex [1] I found... { \newcommand{\dothisicon}{\raisebox{-.5ex}{\includegraphics[height=1.2em]{pharo}}} \newcommand{\dothis}[1]{% \medskip \noindent\dothisicon \ifx#1\empty\else\quad\emph{#1}\fi \par\smallskip\nopagebreak} } and discovered I could do this in the Pillar markup... Before defining a class we should define a package to contain our classes. When we save a package all the classes will be saved together. It is a good practice to group together classes that work together. {{{latex: \dothis{Right-click on the background and open a System Browser.} \dothis{In the package list of the System Browser, choose "add package" to add a new package. Use the name "LaserG }}} to produce in the PDF two Pharo icons on separate lines... But that is awkward and verbose to do each time, and I though it would be nice for Pillar to handle this as an annotation like this... Before defining a class we should define a package to contain our classes. When we save a package all the classes will be saved together. It is a good practice to group together classes that work together. @@dothis Right-click on the background and open a System Browser. @@dothis In the package list of the System Browser, choose "add package" to add a new package. Use the name "LaserGame-Model". so I found I could do that by added the following hack to PRLaTeXWriter>>visitAnnotatedParagraph: ... 'dothis' = anAnnotatedParagraph annotation asLowercase ifTrue: [ ^ self writeRawDuring: [ stream newLine. stream << '\dothis{' . stream << anAnnotatedParagraph text trimBoth . stream << '} ' . ]. ]. However changing this to be less of a hack like this... 'dothis' = anAnnotatedParagraph annotation asLowercase ifTrue: [ ^ canvas command name: 'dothis' ; parameter: [ super visitAnnotatedParagraph: anAnnotatedParagraph ] ]. doesn't quite work, since the first Pharo icon runs onto the previous line... That can be fixed as follows.... PRLaTeXCommand>>name: aString stream newLine. "<---THIS LINE ADDED" stream << $\ << aString but I don't know if that is the right thing to do. Maybe there are times when you want commands to run on from a line. What would be the right thing? Also, is it reasonable to add this new annotation type? i.e. might it be integrated soon ? :) :) . This would really help with the Laser Game tutorial. [1] https://github.com/bencoman/PharoLaserGameTutorial/blob/master/common.tex cheers -ben P.S. This is my first post to the mail list using PostBox on OSX. Let me know if you notice any issues with it being not plain text and if you have any advice ensure plain text posts in PostBox.

10 years, 1 month

ChainAccessor

by Diego Lont

Hi all, I regularly run into the trouble that using a chain accessor gives the error message: MessageNotUnderstood: receiver of “…” is nil. I now spot it faster what I have done wrong here: I use a chain accessor on a un initialised value. I have 3 typical scenario’s where I use a chain accessor: 1. I have a variable that is a collection of some values, that I initialise always, and I want to access its properties. 2. I want to display some extra info, or maybe even allow editing some details of a required “base” value. 3. I want to display some extra info on a “base” value that might be initialised. I propose that on reading, it returns a nil value, when the previous value is nil already. The write method I want to leave as is. Going back to my scenario’s: 1. In this case I guess returning an error would be proper, but on the other hand: I will get this hard error too when I try to write to this variable. So I will still find out I did something wrong (forgot initialisation) when I test properly. 2. In this case, the first time reading generates an error, as the user has not made a choice yet. Returning nil there would be the appropriate behaviour. 3. In this case, returning nil would be the appropriate behaviour, as it only displays information. My question to you all would be: Do you agree that the default behaviour should be to return nil, instead of generate an error? As this would be easier in use? Alternatives: > Modify the description, adding a property that indicates if an error in reading should be blocking or should be interpreted as “nil”. > Create an accessor for each occurrences I have, thus avoiding using a chain accessor (i.e. by using a builder that replaces these accessors). Cheers, Diego

10 years, 1 month

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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki May 2014