September 2011 - Pharo-users

Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:

by Mariano Martinez Peck

On Fri, Sep 9, 2011 at 7:55 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: > On 09/09/2011 10:50 AM, Mariano Martinez Peck wrote: > >> Be careful with SortedCollection instances for example ;) >> > > Yes, SandstoneDb can't store those because of the sort block, store an > OrderedCollection and sort it on the fly when you need it. Maybe I'll add > support since Fuel supports it, but I have a feeling it's a can of worms I > don't want to open for lack of commitment at the moment. Yes, basically because it is likely you will end up serializing a whole stack. If you follow a BlockClosure sender sender sender blah blah home home blah blah yes...it is complicated. > > > -- > Ramon Leon > http://onsmalltalk.com > > -- Mariano http://marianopeck.wordpress.com

Sept. 10, 2011

[COTDC] 84 - FreeTypeCacheLinkedList

by laurent laffont

Today: FreeTypeCacheLinkedList Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

Sept. 10, 2011

Re: [Pharo-users] [Pharo-project] [COTDC] 83 - MCVersionInspector

by laurent laffont

Thanks again Sean Laurent. On Thu, Sep 8, 2011 at 11:06 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I am a tool that visually represents an MCVersion. > > While I can be opened on anMCVersion, you've probably seen me most often > after saving a package in the Monticello Browser. > > I have buttons to perform common version-related actions - like browsing, > loading, and viewing changes. In my main text area, I display the following > information about my version - name, author, timestamp, UUID, ancestors and > log message. > > -- > View this message in context: > http://forum.world.st/COTDC-83-MCVersionInspector-tp3800071p3800124.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Sept. 10, 2011

Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:

by Ramon Leon

On 09/09/2011 11:13 AM, Paul DeBruicker wrote: > Seems like I should just use the onBeforeSave and onAfterSave to switch > between Timepoint instances to DateAndTime for storing the dates and > times. Plus the timeZones. > > Or is there another strategy you'd recommend? > > Thanks That sounds reasonable actually, sort of a manual serialization prep down to raw data. However, you'd need an onLoad as well for a fresh image start from disk. I just realized I don't have a load event; I'll add one. -- Ramon Leon http://onsmalltalk.com

Sept. 9, 2011

Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:

by Paul DeBruicker

> Re: SandstoneDB, Fuel - Contexts must only be created with newForMethod: > > In reply to this post by Paul DeBruicker > On 09/09/2011 10:36 AM, Paul DeBruicker wrote: >> >> #sandstoneDeepCopyVisits: is calling basicNew: on the class MethodContext. > > Because SandstoneDb isn't meant to save special objects like classes, > blocks, or method context's, it's meant to save plain old Smalltalk data > objects from your domain the same way you'd use a relational database. > It's a simple active record data store for quick prototyping based on > serialized files, not a full blown object database that can save every > possible object type. > I've attached the PharoDebug.log. It seems to be choking when trying to save an instance of a RangeConstraint class from the Chronos package. The RangeConstraint class stores two different blocks in two different i-vars. The RangeConstrait is there because I'm saving instances of the Timepoint class from the Chronos package. Seems like I should just use the onBeforeSave and onAfterSave to switch between Timepoint instances to DateAndTime for storing the dates and times. Plus the timeZones. Or is there another strategy you'd recommend? Thanks Paul

Sept. 9, 2011

Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:

by Ramon Leon

On 09/09/2011 10:50 AM, Mariano Martinez Peck wrote: > Be careful with SortedCollection instances for example ;) Yes, SandstoneDb can't store those because of the sort block, store an OrderedCollection and sort it on the fly when you need it. Maybe I'll add support since Fuel supports it, but I have a feeling it's a can of worms I don't want to open for lack of commitment at the moment. -- Ramon Leon http://onsmalltalk.com

Sept. 9, 2011

Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:

by Mariano Martinez Peck

On Fri, Sep 9, 2011 at 7:48 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: > On 09/09/2011 10:36 AM, Paul DeBruicker wrote: > >> >> #sandstoneDeepCopyVisits: is calling basicNew: on the class MethodContext. >> > > Because SandstoneDb isn't meant to save special objects like classes, > blocks, or method context's, it's meant to save plain old Smalltalk data > objects from your domain the same way you'd use a relational database. It's > a simple active record data store for quick prototyping based on serialized > files, not a full blown object database that can save every possible object > type. Be careful with SortedCollection instances for example ;) > > > And I'd guess that it's not a Fuel issue but a SandstoneDB issue because I >> get the same >> error if, when using the same image, in a workspace I change the >> SDSerializer to the >> SDSmartRefStreamSerializer and try again. >> > > Correct. Now, apparently fuel might be able to save some of those special > objects like blocks or classes indeed. Contexts, classes, CompiledMethod, etc... > , but SandstoneDb will throw an error if you attempt to save a class > regardless of what the serializer supports. > > -- > Ramon Leon > http://onsmalltalk.com > > -- Mariano http://marianopeck.wordpress.com

Sept. 9, 2011

Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:

by Mariano Martinez Peck

On Fri, Sep 9, 2011 at 7:44 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > And I'd guess that it's not a Fuel issue but a SandstoneDB issue because I > get the same error if, when using the same image, in a workspace I change > the SDSerializer to the SDSmartRefStreamSerializer and try again. > > I imagine. That's why I've asked. Maybe Ramon can help. You can also attach PharoDebug.log -- Mariano http://marianopeck.wordpress.com

Sept. 9, 2011

Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:

by Ramon Leon

On 09/09/2011 10:36 AM, Paul DeBruicker wrote: > > #sandstoneDeepCopyVisits: is calling basicNew: on the class MethodContext. Because SandstoneDb isn't meant to save special objects like classes, blocks, or method context's, it's meant to save plain old Smalltalk data objects from your domain the same way you'd use a relational database. It's a simple active record data store for quick prototyping based on serialized files, not a full blown object database that can save every possible object type. > And I'd guess that it's not a Fuel issue but a SandstoneDB issue because I get the same > error if, when using the same image, in a workspace I change the SDSerializer to the > SDSmartRefStreamSerializer and try again. Correct. Now, apparently fuel might be able to save some of those special objects like blocks or classes, but SandstoneDb will throw an error if you attempt to save a class regardless of what the serializer supports. -- Ramon Leon http://onsmalltalk.com

Sept. 9, 2011

Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:

by Paul DeBruicker

And I'd guess that it's not a Fuel issue but a SandstoneDB issue because I get the same error if, when using the same image, in a workspace I change the SDSerializer to the SDSmartRefStreamSerializer and try again.

Sept. 9, 2011