March 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Robert Shiplett

Folks, How is the neophyte to be warned that DO IT will be fine, but INSPECT IT will be nasty ? I see nothing to suggest to the user of that bit of HELP to be wary of using that code in a workspace ... What puzzles me is that I was using CTRK-C then CTRL-D ( habit ? ) ... but I also had installed Prof Stef ... and had made the HelpBrowser UNCLOSABLE and SecondFromTop ... it failed pronto when I came to Pharo on this Win7 after it failed in Precise Puppy Linux 4.5 ( the linux netbook is with Japanese books on a big work table outside this little office but I recall steps as Start, load Prof Stef, walk thru some Stef steps; open Sys Browser, go to Announcements, open HelpBrowser ) error handling fails BUT recovery is about 3 steps (CR, exit, abort debugger ) so that much is Very good ... friend among friendly folks, R Canada On 19 March 2013 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Robert, > > The following two work for me in Pharo 2.0 > > World announcer > on: WindowOpened > send: #value > to: [ Transcript show: 'A new window was opened'; cr ]. > > World announcer > on: WindowOpened > send: #value: > to: [ :announcement | > Transcript show: 'A new window was opened ', > announcement printString; cr ]. > > Note the #value and #value: selectors, matching the zero and one argument > blocks. > > I would guess that opening the Inspector inside the block creates an > infinite loop ;-) > > Sven > > On 19 Mar 2013, at 15:47, Robert Shiplett <grshiplett(a)gmail.com> wrote: > > > Pharo 2.0 > > HelpBrowser Announcements STEP 3 > > > > QUOTE: > > > > In Pharo there is a global called "World" pointing to the desktop morph. > This world also has an announcer we can use to demonstrate the features of > the framework: > > > > | announcer | > > World announcer > > on: WindowOpened > > send: #value > > to: [ Transcript show: 'A new window was opened';cr]. > > > > So anytime a window is opened in the system a message is shown in the > transcript: > > > > Transcript open. > > > > | announcer | > > World announcer > > on: WindowOpened > > send: #value > > to: [:ea | ea inspect. Transcript show: 'A new window was > opened';cr]. > > > > > > >

March 19, 2013

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Sven Van Caekenberghe

Hi Robert, The following two work for me in Pharo 2.0 World announcer on: WindowOpened send: #value to: [ Transcript show: 'A new window was opened'; cr ]. World announcer on: WindowOpened send: #value: to: [ :announcement | Transcript show: 'A new window was opened ', announcement printString; cr ]. Note the #value and #value: selectors, matching the zero and one argument blocks. I would guess that opening the Inspector inside the block creates an infinite loop ;-) Sven On 19 Mar 2013, at 15:47, Robert Shiplett <grshiplett(a)gmail.com> wrote: > Pharo 2.0 > HelpBrowser Announcements STEP 3 > > QUOTE: > > In Pharo there is a global called "World" pointing to the desktop morph. This world also has an announcer we can use to demonstrate the features of the framework: > > | announcer | > World announcer > on: WindowOpened > send: #value > to: [ Transcript show: 'A new window was opened';cr]. > > So anytime a window is opened in the system a message is shown in the transcript: > > Transcript open. > > | announcer | > World announcer > on: WindowOpened > send: #value > to: [:ea | ea inspect. Transcript show: 'A new window was opened';cr]. > >

March 19, 2013

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Robert Shiplett

In all fairness, I DID say ' the code in "examples" of Step 3 of the Announcements "book" in the HelpBrowser ? ' that is all it is - some help notes with 2 code snippets ; both snippets are nasty when used as directed. Announcements likely will be new to anyone who has not seen Smalltalk for a few years ... Or no ?

March 19, 2013

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Marcus Denker

On Mar 19, 2013, at 3:55 PM, Robert Shiplett <grshiplett(a)gmail.com> wrote: > 1988 MS QuickHelp ( in what was THEN called QuickHelp ) allowed user annotations in the Help ;-) QuickBasic / Quick C with Assembler > Borland C++ for OS/2 still remains my fave enviro as I could use it for compiling Large DOS programs to be called by Prolog ( I was PROLOG before Smalltalk ;-) > > I will try to remember to post offending snippets if I hit any more of them as I go about with my "Be-A-Neophyte" in the bowels hat/chapeau on my haid ... with a phare on my casque as all good speliologists do it ... ;-) > You know, it is very hard to fix things if people don't say what is brokenâ¦ Marcus > > On 19 March 2013 11:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Robert, > > On 19 Mar 2013, at 13:10, Robert Shiplett <grshiplett(a)gmail.com> wrote: > > > Could you or someone on team look at the code in "examples" of Step 3 of the Announcements "book" in the HelpBrowser ? > > > > This has caused emerg in linux x86 on an Atom netbook and Win7 64-bit HoPr Sp1 on an i7 with the 2.0 release ... not the intended result ... > > > > I have the silly idea that in a "base" release of a 2.0 St that any neophyte should be able to trust code 1) to be an exemplar of St best practices 2) not to cause newbie panic [ I well remember my first couple of days with Smalltalk/PM on OS/2 1.3 ( ? surely not OS/2 2.0 ) after being so pleased with MS QuickHelp for MS DOS "Quick C with Assembler" ;-) ] ( to loop from '87 Zenith Eazy PC 512k to 2009 Asus EeePC 900A ;-) > > Smalltalk is one of the ultimate malleable systems: you can literally change everything, including the whole infrastructure the system is built on. So yes, you can shoot yourself in the foot. > > On the other hand, I agree that Pharo should be as stable as possible: the VM should not crash and a proper exception and debugger should always pop up. [ But again, the debugger and exception system are implemented in Smalltalk and you can change/break them ]. > > Maybe you could provide the actual code snippet ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

March 19, 2013

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Robert Shiplett

1988 MS QuickHelp ( in what was THEN called QuickHelp ) allowed user annotations in the Help ;-) QuickBasic / Quick C with Assembler Borland C++ for OS/2 still remains my fave enviro as I could use it for compiling Large DOS programs to be called by Prolog ( I was PROLOG before Smalltalk ;-) I will try to remember to post offending snippets if I hit any more of them as I go about with my "Be-A-Neophyte" in the bowels hat/chapeau on my haid ... with a phare on my casque as all good speliologists do it ... ;-) On 19 March 2013 11:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Robert, > > On 19 Mar 2013, at 13:10, Robert Shiplett <grshiplett(a)gmail.com> wrote: > > > Could you or someone on team look at the code in "examples" of Step 3 of > the Announcements "book" in the HelpBrowser ? > > > > This has caused emerg in linux x86 on an Atom netbook and Win7 64-bit > HoPr Sp1 on an i7 with the 2.0 release ... not the intended result ... > > > > I have the silly idea that in a "base" release of a 2.0 St that any > neophyte should be able to trust code 1) to be an exemplar of St best > practices 2) not to cause newbie panic [ I well remember my first couple of > days with Smalltalk/PM on OS/2 1.3 ( ? surely not OS/2 2.0 ) after being so > pleased with MS QuickHelp for MS DOS "Quick C with Assembler" ;-) ] ( to > loop from '87 Zenith Eazy PC 512k to 2009 Asus EeePC 900A ;-) > > Smalltalk is one of the ultimate malleable systems: you can literally > change everything, including the whole infrastructure the system is built > on. So yes, you can shoot yourself in the foot. > > On the other hand, I agree that Pharo should be as stable as possible: the > VM should not crash and a proper exception and debugger should always pop > up. [ But again, the debugger and exception system are implemented in > Smalltalk and you can change/break them ]. > > Maybe you could provide the actual code snippet ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

March 19, 2013

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Robert Shiplett

Pharo 2.0 HelpBrowser Announcements STEP 3 QUOTE: In Pharo there is a global called "World" pointing to the desktop morph. This world also has an announcer we can use to demonstrate the features of the framework: | announcer | World announcer on: WindowOpened send: #value to: [ Transcript show: 'A new window was opened';cr]. So anytime a window is opened in the system a message is shown in the transcript: Transcript open. | announcer | World announcer on: WindowOpened send: #value to: [:ea | ea inspect. Transcript show: 'A new window was opened';cr].

March 19, 2013

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Sven Van Caekenberghe

Robert, On 19 Mar 2013, at 13:10, Robert Shiplett <grshiplett(a)gmail.com> wrote: > Could you or someone on team look at the code in "examples" of Step 3 of the Announcements "book" in the HelpBrowser ? > > This has caused emerg in linux x86 on an Atom netbook and Win7 64-bit HoPr Sp1 on an i7 with the 2.0 release ... not the intended result ... > > I have the silly idea that in a "base" release of a 2.0 St that any neophyte should be able to trust code 1) to be an exemplar of St best practices 2) not to cause newbie panic [ I well remember my first couple of days with Smalltalk/PM on OS/2 1.3 ( ? surely not OS/2 2.0 ) after being so pleased with MS QuickHelp for MS DOS "Quick C with Assembler" ;-) ] ( to loop from '87 Zenith Eazy PC 512k to 2009 Asus EeePC 900A ;-) Smalltalk is one of the ultimate malleable systems: you can literally change everything, including the whole infrastructure the system is built on. So yes, you can shoot yourself in the foot. On the other hand, I agree that Pharo should be as stable as possible: the VM should not crash and a proper exception and debugger should always pop up. [ But again, the debugger and exception system are implemented in Smalltalk and you can change/break them ]. Maybe you could provide the actual code snippet ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 19, 2013

Re: [Pharo-users] NeoJSON Mappings

by Sven Van Caekenberghe

On 19 Mar 2013, at 13:14, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > Yes, I find out that. > But I wanted to have the JSON serialization to be context-dependant. > > And that's what I achieved by means of the custom mappings. > > Again, kudos for making it so fast and memory-savvy, being stream based with > no internal transformations makes it almost a basic printOn: aStream. Thanks, that was indeed the idea. > One question that remains is... how to map the same accesor/instVar to more > than one attribute. > eg. > neoJsonMapping: mapper > > mapper for: self do: [:mapping | > mapping mapAccessor: #reference. "full" > (mapping mapAccessor: #reference to: 'reference-id) valueSchema: > #ReferenceId "just its ID" > ]. > > mapper for: #ReferenceId customDo: [:mapping | > mapper encoder: [:obj | obj id printString ] > "..." > ] > > If I do that, I end up having the full reference twice. I think I understand what you want, and I know that you tried to explain the model (or a minimal version of it), but if you are writing out JSON according to some externally defined format (with the ideas and sharing), would it be possible to give me the specification of that format ? Maybe off list ? In any case, I will think about the issue you raised. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 19, 2013

Re: [Pharo-users] NeoJSON Mappings

by Esteban A. Maringolo

Yes, I find out that. But I wanted to have the JSON serialization to be context-dependant. And that's what I achieved by means of the custom mappings. Again, kudos for making it so fast and memory-savvy, being stream based with no internal transformations makes it almost a basic printOn: aStream. One question that remains is... how to map the same accesor/instVar to more than one attribute. eg. neoJsonMapping: mapper mapper for: self do: [:mapping | mapping mapAccessor: #reference. "full" (mapping mapAccessor: #reference to: 'reference-id) valueSchema: #ReferenceId "just its ID" ]. mapper for: #ReferenceId customDo: [:mapping | mapper encoder: [:obj | obj id printString ] "..." ] If I do that, I end up having the full reference twice. Regards! -- View this message in context: http://forum.world.st/NeoJSON-Mappings-tp4677077p4677288.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 19, 2013

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Robert Shiplett

Could you or someone on team look at the code in "examples" of Step 3 of the Announcements "book" in the HelpBrowser ? This has caused emerg in linux x86 on an Atom netbook and Win7 64-bit HoPr Sp1 on an i7 with the 2.0 release ... not the intended result ... I have the silly idea that in a "base" release of a 2.0 St that any neophyte should be able to trust code 1) to be an exemplar of St best practices 2) not to cause newbie panic [ I well remember my first couple of days with Smalltalk/PM on OS/2 1.3 ( ? surely not OS/2 2.0 ) after being so pleased with MS QuickHelp for MS DOS "Quick C with Assembler" ;-) ] ( to loop from '87 Zenith Eazy PC 512k to 2009 Asus EeePC 900A ;-)

March 19, 2013