- Pharo-users - lists.pharo.org

Re: [Pharo-users] Serializing an error (Fuel)

by Bernat Romagosa

Hi Mariano, We're stuck on Pharo 1.4 until Iliad and some other packages are available for 2.0... however, I'll try to update it to the latest possible version and see if it still happens. Thanks! 2013/4/29 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > > On Mon, Apr 29, 2013 at 6:30 AM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > >> Hi list, >> >> Until recently, we've been dealing with all errors in our Iliad >> application by having the Iliad error handler serialize them and send us an >> email referring to the file. >> >> This way, debugging was as easy as: >> >> *GRPlatform current openDebuggerOn: (FLMaterializer >> materializeFromFileNamed: 'errorReports/1366980822.obj'). >> * >> >> But recently this has stopped working, and I've just found out I can't >> even serialize simple errors. Something like: >> >> *[ 3 / 0 ] on: Error do: [ :error | FLSerializer >> serialize: error toFileNamed: 'error.obj' ] >> * >> >> brings out a debugger saying I need FuelMetalevel to fully serialize >> methods (which is installed, by the way). The error reads: >> >> *FLNotInstalledMethod: Serialization error. DoIt can not be serialized >> as global because it is not installed. You need FuelMetalevel to fully >> serialize methods. See the documentation.* >> > > > This is old. Fuel 1.9 (last stable version and the one integrated in Pharo > 2.0) should be able to fully serialize methods. Moreover, it automatically > serialize uninstalled methods and do-its. > > cheers, > > >> >> I'm not sure whether one thing is related to the other... any ideas? >> >> -- >> Bernat Romagosa. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Bernat Romagosa.

April 29, 2013

Re: [Pharo-users] Serializing an error (Fuel)

by Mariano Martinez Peck

On Mon, Apr 29, 2013 at 6:30 AM, Bernat Romagosa < tibabenfortlapalanca(a)gmail.com> wrote: > Hi list, > > Until recently, we've been dealing with all errors in our Iliad > application by having the Iliad error handler serialize them and send us an > email referring to the file. > > This way, debugging was as easy as: > > *GRPlatform current openDebuggerOn: (FLMaterializer > materializeFromFileNamed: 'errorReports/1366980822.obj'). > * > > But recently this has stopped working, and I've just found out I can't > even serialize simple errors. Something like: > > *[ 3 / 0 ] on: Error do: [ :error | FLSerializer > serialize: error toFileNamed: 'error.obj' ] > * > > brings out a debugger saying I need FuelMetalevel to fully serialize > methods (which is installed, by the way). The error reads: > > *FLNotInstalledMethod: Serialization error. DoIt can not be serialized as > global because it is not installed. You need FuelMetalevel to fully > serialize methods. See the documentation.* > This is old. Fuel 1.9 (last stable version and the one integrated in Pharo 2.0) should be able to fully serialize methods. Moreover, it automatically serialize uninstalled methods and do-its. cheers, > > I'm not sure whether one thing is related to the other... any ideas? > > -- > Bernat Romagosa. > -- Mariano http://marianopeck.wordpress.com

April 29, 2013

Re: [Pharo-users] Serializing an error (Fuel)

by Bernat Romagosa

Ouch! Disregard that. I've just tried to serialize an error from the Iliad error handler and it worked... not sure what was going on! Sorry! 2013/4/29 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > Hi list, > > Until recently, we've been dealing with all errors in our Iliad > application by having the Iliad error handler serialize them and send us an > email referring to the file. > > This way, debugging was as easy as: > > *GRPlatform current openDebuggerOn: (FLMaterializer > materializeFromFileNamed: 'errorReports/1366980822.obj'). > * > > But recently this has stopped working, and I've just found out I can't > even serialize simple errors. Something like: > > *[ 3 / 0 ] on: Error do: [ :error | FLSerializer > serialize: error toFileNamed: 'error.obj' ] > * > > brings out a debugger saying I need FuelMetalevel to fully serialize > methods (which is installed, by the way). The error reads: > > *FLNotInstalledMethod: Serialization error. DoIt can not be serialized as > global because it is not installed. You need FuelMetalevel to fully > serialize methods. See the documentation.* > > I'm not sure whether one thing is related to the other... any ideas? > > -- > Bernat Romagosa. > -- Bernat Romagosa.

April 29, 2013

Serializing an error (Fuel)

by Bernat Romagosa

Hi list, Until recently, we've been dealing with all errors in our Iliad application by having the Iliad error handler serialize them and send us an email referring to the file. This way, debugging was as easy as: *GRPlatform current openDebuggerOn: (FLMaterializer materializeFromFileNamed: 'errorReports/1366980822.obj'). * But recently this has stopped working, and I've just found out I can't even serialize simple errors. Something like: *[ 3 / 0 ] on: Error do: [ :error | FLSerializer serialize: error toFileNamed: 'error.obj' ] * brings out a debugger saying I need FuelMetalevel to fully serialize methods (which is installed, by the way). The error reads: *FLNotInstalledMethod: Serialization error. DoIt can not be serialized as global because it is not installed. You need FuelMetalevel to fully serialize methods. See the documentation.* I'm not sure whether one thing is related to the other... any ideas? -- Bernat Romagosa.

April 29, 2013

Re: [Pharo-users] Want to connect two morphs with a line.

by stephane ducasse

a slice is simply a package with dependencies. Normally loading a slice loads its dependent packages. So this is handy to get all the changes touching several packages in one click. Stef On Apr 27, 2013, at 8:50 PM, Zeeshan Ansari <zeeshan.k.ansari(a)gmail.com> wrote: > Hello, > > I'm having trouble loading a slice. What exactly is that and how do I load it into my Image. Does this need to be run on Pharo 2.0 or can I use it on 1.4? > Once I file in the changes, how do I run the example. > > Thanks. > > > On Thu, Apr 25, 2013 at 12:33 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Load Slice 10407, because without it, no easy way to define your own TransferMorph > > You can have a look at the code attached, it defined a simple Spec UI (you can easily find the Morphic part in it), > and a subclass of TransferMorph creating a from the draggedItem to the mouse. > > This Morph is usable in a fully Morphic UI, so it may interest you :) > (it's a pro to, so the code is not documented, sorry) > > > > Ben > > On Apr 25, 2013, at 5:14 PM, Zeeshan Ansari <zeeshan.k.ansari(a)gmail.com> wrote: > >> I have looked into that but I'm trying to do something a lot more simpler. This is basically for a school project and I'm trying to learn the Morphic framework. >> >> >> On Thu, Apr 25, 2013 at 8:51 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >> Hi, >> >> Carla did the SmallUML GSoc in 2010. >> She also provided a MinimalConnector library to do this IIRC. >> >> http://www.squeaksource.com/smallUML >> >> Maybe it is what you are looking for. >> >> Luc >> >> >> #Luc >> >> >> 2013/4/25 Zeeshan Ansari <zeeshan.k.ansari(a)gmail.com> >> Hi All, >> I want to connect two morphs with a line for a UML editor application I'm working on. I want to show the line being created as the user moves the mouse from the source morph to the target morph. Once the mouse is over the target morph and the mouse released, the line should be created. >> >> Can someone explain how I would go about doing this. Which events would I need to capture, etc. >> >> Thanks. >> >> >> > > >

April 27, 2013

Re: [Pharo-users] Want to connect two morphs with a line.

by Zeeshan Ansari

Hello, I'm having trouble loading a slice. What exactly is that and how do I load it into my Image. Does this need to be run on Pharo 2.0 or can I use it on 1.4? Once I file in the changes, how do I run the example. Thanks. On Thu, Apr 25, 2013 at 12:33 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Load Slice 10407, because without it, no easy way to define your own > TransferMorph > > You can have a look at the code attached, it defined a simple Spec UI (you > can easily find the Morphic part in it), > and a subclass of TransferMorph creating a from the draggedItem to the > mouse. > > This Morph is usable in a fully Morphic UI, so it may interest you :) > (it's a pro to, so the code is not documented, sorry) > > > > Ben > > On Apr 25, 2013, at 5:14 PM, Zeeshan Ansari <zeeshan.k.ansari(a)gmail.com> > wrote: > > I have looked into that but I'm trying to do something a lot more simpler. > This is basically for a school project and I'm trying to learn the Morphic > framework. > > > On Thu, Apr 25, 2013 at 8:51 AM, Luc Fabresse <luc.fabresse(a)gmail.com>wrote: > >> Hi, >> >> Carla did the SmallUML GSoc in 2010. >> She also provided a MinimalConnector library to do this IIRC. >> >> http://www.squeaksource.com/smallUML >> >> Maybe it is what you are looking for. >> >> Luc >> >> >> #Luc >> >> >> 2013/4/25 Zeeshan Ansari <zeeshan.k.ansari(a)gmail.com> >> >>> Hi All, >>> I want to connect two morphs with a line for a UML editor application >>> I'm working on. I want to show the line being created as the user moves the >>> mouse from the source morph to the target morph. Once the mouse is over the >>> target morph and the mouse released, the line should be created. >>> >>> Can someone explain how I would go about doing this. Which events would >>> I need to capture, etc. >>> >>> Thanks. >>> >> >> > > >

April 27, 2013

Re: [Pharo-users] CommandShell - linux - missing directory in path

by Sean P. DeNigris

Ben Coman wrote > the McDonalds Burger Principle I think you meant "70+ year marketing campaign targeted at small children" -> success. But we get the point ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/CommandShell-linux-missing-directory-in-path-tp468366… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 27, 2013

Re: [Pharo-users] Monticello - break up a package

by Dale Henrichs

Ingo, The basic sequence is to create _new_ package called SandstoneDbPharo20 this is where you'll put the Pharo2.0-specific methods ... I assume that you had to override some methods in the base Sandstone package, if so, you'll also need to create another _new_ package called SandstoneDbCommon (perhaps others can suggest better names ... I seem to always pick the wrong names:). This is where you'll put the FileDirectory based methods for use by all of the other platforms. At this point you'll have three SandstoneDb packages in your image and I'm assuming that right now you will have the SandstoneDB package with your updates loaded. Start by doing a diff of your package against the package version that you started with. For each of the methods that you _changed_ you will need to move the method into the SandstoneDbPharo20 package by creating a *SandstoneDbPharo20 method category in the class and move the method(s) into that category. If there are any new Pharo2.0 methods "move" those methods into the SandstoneDbPharo20. If you have deleted any methods for Pharo2.0, make a note (leave the diff window open), because you will want to "move" those methods into the SandstoneDbCommon package. When you've accounted for all of the changes, save all three packages... After saving, unload all three packages and load the SandstoneDb package that you started with (the one you used for diff). Load the SandstoneDbCommon package. And repeat the process: "move" all of the methods changed changed for Pharo2.0 into SandstoneDbCommon (using the category name *SandstoneDbCommon) and "move" all of the methods that were deleted for Pharo2.0 into SandstoneDbCommon. Save the the two dirty packages... At this point, I think you've accomplished the "break out my changes to the file store into another package, so that it is possible to just use the appropriate package for different Smalltalk versions" plus a little bit more:). The next step is to update the configuration with the new packages and their dependencies, but perhaps Ramon will do that? Hope this helps, Dale ----- Original Message ----- | From: "Ingo Hohmann" <pharo(a)ingohohmann.de> | To: "pharo-users" <pharo-users(a)lists.gforge.inria.fr> | Sent: Thursday, April 25, 2013 10:28:36 PM | Subject: [Pharo-users] Monticello - break up a package | | Following up on my quest to get SandstoneDb to run on Pharo 2.0. | Ramon asked me to break out my changes to the file store into another | package, so that it is possible to just use the appropriate package for | different Smalltalk versions. | | Now, how do I best do that? When I tried it before, I got a new package | with no acestors, but the same content still in the "base" package. | | Thank you for your help so far. | | | Kind regards, | | Ingo |

April 27, 2013

Re: [Pharo-users] CommandShell - linux - missing directory in path

by Ben Coman

Igor Stasenko wrote: > On 26 April 2013 16:11, Ingo Hohmann <pharo(a)ingohohmann.de> wrote: > >> Hi Mariano, >> >> actually the $PATH is correctly taken from my system settings, it's broken >> in the system settings. >> >> The idea from Camillo works, as well as changing the $PATH on the system. >> >> The remaining question is: should this be reported as a bug? (I tend to yes) >> >> > > so, i don't have strong opinion on it.. but maybe you right, and CommandShell > should behave similar to OS shell (in respect that in cases if OS > shell don't barks, neither CommandShell should). > > It should not deviate unnecessarily from existing conventions. Its not always good to make it "better" if that conflicts with Principle Of Least Surprise. A corollary is the McDonalds Burger Principle, its not the best burger in the world, but it is the same in every store in the world --> success. cheers -ben >> Thank you, >> >> Ingo >> >> > >

April 27, 2013

Re: [Pharo-users] NativeBoost

by Rocio Amaya

Thank you all for the help! :) Best Regards.

April 26, 2013