January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

by Sebastian Sastre

Makes sense. Thanks Stef I will On Jan 3, 2014, at 7:41 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Sebastian > > You should consider that often there were no decision: just old code designed sometimes > even before Design Patterns and any of the book on oo design we know today. > No more. Then the system grew organically, then we arrived and started to revisit but > sometimes we did not see the original intention because they were many layers/authors/stylesâ¦. > > Now if you want to see the situation improving: build a serious case, spend some time > analysing it (I mean more than writing a mail) and make a proposal. We will discuss and probably converge and improve the system. > > Stef > > On 03 Jan 2014, at 19:41, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Yeah Sven, I know timezones can be hell. >> >> Actually for me this isn't an issue as already ported my code with asDate and asTime. >> >> What worries me is the thinking behind that omission >> >> Why? >> >> Because you don't know where it will bite you next. >> >> But it will >> >> And it wont be intuitive >> >> >> >> >> On Jan 3, 2014, at 4:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> I canât defend the API choice. >>> >>> But consider this: contrary to the name, a DateAndTime is much more that just a Date + a Time, it has a timezone offset and fractional seconds. That could be reason why there are #asDate and #asTime as conversion methods instead of #date and #time as accessors. On the other hand, there are lots of other accessors for all components. Maybe that is why #date and #time were not implemented: you would expect taking the date and time from a dateAndTime and composing them again would yield the original object, but that would not work. >>> >>> On 03 Jan 2014, at 19:03, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>> >>>> yeah is what I'm using now but the 'as' means conversion while the #date and #time suggest delegating access to the other guy >>>> >>>> returning to the question.. is that omission intentional then? >>>> >>>> I mean.. >>>> >>>> There are counter intuitive things that are cool. >>>> >>>> This isn't one of those. >>>> >>>> This one sounds a lot against intuition for no good reason >>>> >>>> sebastian >>>> >>>> o/ >>>> >>>> >>>> >>>> >>>> >>>> On Jan 3, 2014, at 3:55 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> >>>>> On 03 Jan 2014, at 18:50, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>>>> >>>>>> How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight) >>>>>> >>>>>> Sorry for the drama but hey... the raison d'Ãªtre, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D >>>>>> >>>>>> How come that the most basic ones are being omitted? >>>>>> >>>>>> Am I missing something? >>>>> >>>>> #asDate and #asTime ? >>>>> >>>>>> sebastian >>>>>> >>>>>> o/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >

Jan. 3, 2014

Re: [Pharo-dev] SIXX on "large" files

by Sebastian Sastre

I've discovered that its part of a JsonObject that holds the facebook profile associated with the user. SIXX is cool but I'm with the feeling that it's time to give fuel a chance On Jan 3, 2014, at 8:01 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 3 January 2014 20:07, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> It's probable unrelated to size as expected. >> >> For the record: >> >> I've changed the XMLParser and the new one complained about a problem on a >> specific line that has this content >> >> <sixx.object sixx.id="1106" sixx.name="key" sixx.type="String" >>> name</sixx.object> >> <sixx.object sixx.id="1107" sixx.name="value" sixx.type="String" >>> Like >> Mark >> Twain: >>  >> I've >> never >> let >> my >> school >> interfere >> with >> my >> education. >> </sixx.object> >> </sixx.object> >> >> looks like an encoding problem > > Was that originally a UTF-32 string or something? Three NULs followed > by a character... (For the curious, it says 'Like Mark Twain: "I've > never let my school interfere with my education. "') > > frank >

Jan. 3, 2014

Re: [Pharo-dev] SIXX on "large" files

by Sebastian Sastre

On Jan 3, 2014, at 7:43 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> I've changed the XMLParser > > how? With this guy: ConfigurationOfXMLParser load. from MetaRepoForPharo30

Jan. 3, 2014

Soundplugin for Windows/Linux

by Nicolai Hess

Can someone change PharoVM build configs regarding issue 12493 <https://pharo.fogbugz.com/default.asp?12493> Sound does not work for Windows and Linux VMs because windows) PharoVMBuilder does not include soundplugin in the windows config linux) vm-sound-alsa has unresolved externals -> can not be loaded squeaks vm-sound-oss and vm-sound-pulse are working with pharo too vm-sound-oss source is in pharos vm source, but not in pharovmbuilders config, so it just isn't built. For me, it looks like it is solveable by just changing PharoVMBuilder configs. I built my own VMs for Windows (Windows 7 32Bit) and Linux (Ubuntu 10.04), and it works. But I don't know if the exclusion of this plugins is on purpose because they may make problems on other Win/Linux versions. Nicolai

Jan. 3, 2014

Re: [Pharo-dev] SIXX on "large" files

by Frank Shearar

On 3 January 2014 20:07, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > It's probable unrelated to size as expected. > > For the record: > > I've changed the XMLParser and the new one complained about a problem on a > specific line that has this content > > <sixx.object sixx.id="1106" sixx.name="key" sixx.type="String" >>name</sixx.object> > <sixx.object sixx.id="1107" sixx.name="value" sixx.type="String" >>Like > Mark > Twain: >  > I've > never > let > my > school > interfere > with > my > education. > </sixx.object> > </sixx.object> > > looks like an encoding problem Was that originally a UTF-32 string or something? Three NULs followed by a character... (For the curious, it says 'Like Mark Twain: "I've never let my school interfere with my education. "') frank

Jan. 3, 2014

Re: [Pharo-dev] [Glass] printString and asString

by StÃ©phane Ducasse

I agree and especially on the fact that conversion methods should be between âpolymorphicâ objects else we end up having everything converted/able. this is why asOrderedCollection asBagâ¦ are all between collections. So a good proposal would be to understand if we can remove asString from Object. stef On 03 Jan 2014, at 20:55, Martin McClure <martin(a)hand2mouse.com> wrote: > On 01/03/2014 12:33 AM, Otto Behrens wrote: >> Hi, >> >> I've run into one of my favorite problems in Smalltalk and decided to >> try the list. Please don't shoot me on this one; perhaps you've run >> into it yourself. If there are discussions that I should read, please >> send me some info. > > Hi Otto, > > Well, you asked for comments. This is my personal opinion, which varies > quite a bit from most implementations, since it's a bit 'old-school > Smalltalk'. But I think the scheme below does fairly neatly distinguish > the purposes of the various messages, which have gotten muddied over the > years as new developers use the language somewhat differently. But maybe > it was never the way I think I remember it being. :-) > > > #printString and #printOn: > These should answer a human-readable description of the receiver. The > description does not need to include the class name, though it can. All > objects should respond to these messages. Generally, #printString should > be implemented in terms of #printOn: -- if you're writing to a stream > you may not want to pay the cost of creating an extra string. > #printString is the equivalent of other languages' toString(). > > #asString > There should not be an Object>>asString. This message is *only* for > converting string-like things to actual strings. So it would be > implemented in String (to return self) and in Symbol, and *maybe* in > things like ByteArray (where it does not *describe* the byte array, but > answers a string whose characters have the values of the bytes). > > #storeString > Produces legal Smalltalk source code that when executed will produce an > equivalent object to the receiver. Needs to be implemented only for > objects that can be specified as literals in Smalltalk syntax, but could > probably be implemented for a few other simple objects. > > #displayString and so on. > UI frameworks and applications will need to have their own ways of > textually representing objects, so will add their own messages such as > #displayString. The *only* messages that any application or framework > can depend on *all* objects responding to are those that it defines > itself, and #printString and #printOn:. > > Regards, > > -Martin >

Jan. 3, 2014

Re: [Pharo-dev] SIXX on "large" files

by StÃ©phane Ducasse

On 03 Jan 2014, at 21:07, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > It's probable unrelated to size as expected. > > For the record: > > I've changed the XMLParser how? I do not know if SIxx fixes the version of the XML parser it uses. > and the new one complained about a problem on a specific line that has this content > > <sixx.object sixx.id="1106" sixx.name="key" sixx.type="String" >name</sixx.object> > <sixx.object sixx.id="1107" sixx.name="value" sixx.type="String" >Like Mark Twain:  I've never let my school interfere with my education. </sixx.object> > </sixx.object> > > looks like an encoding problem > > > > On Jan 3, 2014, at 5:59 PM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: > >> Hi guys, >> >> anyone here using SIXX? >> >> I'm having a consistent problem in opening a SixxReadStream on a file that has ~10MB of serialized objects. >> >> Smaller than that is all good >> >> Bigger, raises SixxXmlParseError >> >> ideas? >> >> Maybe I'm using the wrong version of XMLDOMParser? >> >> patches? workarounds? >> >> sebastian >> >> o/ >> >> PD: sixx was loaded with: >> >> Gofer it >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfSIXX'; >> load. >> >> (Smalltalk at: #ConfigurationOfSIXX) project latestVersion load. >> >> >> >

Jan. 3, 2014

Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

by StÃ©phane Ducasse

Sebastian You should consider that often there were no decision: just old code designed sometimes even before Design Patterns and any of the book on oo design we know today. No more. Then the system grew organically, then we arrived and started to revisit but sometimes we did not see the original intention because they were many layers/authors/stylesâ¦. Now if you want to see the situation improving: build a serious case, spend some time analysing it (I mean more than writing a mail) and make a proposal. We will discuss and probably converge and improve the system. Stef On 03 Jan 2014, at 19:41, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Yeah Sven, I know timezones can be hell. > > Actually for me this isn't an issue as already ported my code with asDate and asTime. > > What worries me is the thinking behind that omission > > Why? > > Because you don't know where it will bite you next. > > But it will > > And it wont be intuitive > > > > > On Jan 3, 2014, at 4:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> I canât defend the API choice. >> >> But consider this: contrary to the name, a DateAndTime is much more that just a Date + a Time, it has a timezone offset and fractional seconds. That could be reason why there are #asDate and #asTime as conversion methods instead of #date and #time as accessors. On the other hand, there are lots of other accessors for all components. Maybe that is why #date and #time were not implemented: you would expect taking the date and time from a dateAndTime and composing them again would yield the original object, but that would not work. >> >> On 03 Jan 2014, at 19:03, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>> yeah is what I'm using now but the 'as' means conversion while the #date and #time suggest delegating access to the other guy >>> >>> returning to the question.. is that omission intentional then? >>> >>> I mean.. >>> >>> There are counter intuitive things that are cool. >>> >>> This isn't one of those. >>> >>> This one sounds a lot against intuition for no good reason >>> >>> sebastian >>> >>> o/ >>> >>> >>> >>> >>> >>> On Jan 3, 2014, at 3:55 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 03 Jan 2014, at 18:50, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>>> >>>>> How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight) >>>>> >>>>> Sorry for the drama but hey... the raison d'Ãªtre, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D >>>>> >>>>> How come that the most basic ones are being omitted? >>>>> >>>>> Am I missing something? >>>> >>>> #asDate and #asTime ? >>>> >>>>> sebastian >>>>> >>>>> o/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >

Jan. 3, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Tudor Girba

Thanks, Martin. I second your summary. Doru On Fri, Jan 3, 2014 at 8:55 PM, Martin McClure <martin(a)hand2mouse.com>wrote: > On 01/03/2014 12:33 AM, Otto Behrens wrote: > > Hi, > > > > I've run into one of my favorite problems in Smalltalk and decided to > > try the list. Please don't shoot me on this one; perhaps you've run > > into it yourself. If there are discussions that I should read, please > > send me some info. > > Hi Otto, > > Well, you asked for comments. This is my personal opinion, which varies > quite a bit from most implementations, since it's a bit 'old-school > Smalltalk'. But I think the scheme below does fairly neatly distinguish > the purposes of the various messages, which have gotten muddied over the > years as new developers use the language somewhat differently. But maybe > it was never the way I think I remember it being. :-) > > > #printString and #printOn: > These should answer a human-readable description of the receiver. The > description does not need to include the class name, though it can. All > objects should respond to these messages. Generally, #printString should > be implemented in terms of #printOn: -- if you're writing to a stream > you may not want to pay the cost of creating an extra string. > #printString is the equivalent of other languages' toString(). > > #asString > There should not be an Object>>asString. This message is *only* for > converting string-like things to actual strings. So it would be > implemented in String (to return self) and in Symbol, and *maybe* in > things like ByteArray (where it does not *describe* the byte array, but > answers a string whose characters have the values of the bytes). > > #storeString > Produces legal Smalltalk source code that when executed will produce an > equivalent object to the receiver. Needs to be implemented only for > objects that can be specified as literals in Smalltalk syntax, but could > probably be implemented for a few other simple objects. > > #displayString and so on. > UI frameworks and applications will need to have their own ways of > textually representing objects, so will add their own messages such as > #displayString. The *only* messages that any application or framework > can depend on *all* objects responding to are those that it defines > itself, and #printString and #printOn:. > > Regards, > > -Martin > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

Re: [Pharo-dev] SIXX on "large" files

by Sebastian Sastre

It's probable unrelated to size as expected. For the record: I've changed the XMLParser and the new one complained about a problem on a specific line that has this content <sixx.object sixx.id="1106" sixx.name="key" sixx.type="String" >name</sixx.object> <sixx.object sixx.id="1107" sixx.name="value" sixx.type="String" >Like Mark Twain:  I've never let my school interfere with my education. </sixx.object> </sixx.object> looks like an encoding problem On Jan 3, 2014, at 5:59 PM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: > Hi guys, > > anyone here using SIXX? > > I'm having a consistent problem in opening a SixxReadStream on a file that has ~10MB of serialized objects. > > Smaller than that is all good > > Bigger, raises SixxXmlParseError > > ideas? > > Maybe I'm using the wrong version of XMLDOMParser? > > patches? workarounds? > > sebastian > > o/ > > PD: sixx was loaded with: > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSIXX'; > load. > > (Smalltalk at: #ConfigurationOfSIXX) project latestVersion load. > > >

Jan. 3, 2014