- Pharo-dev - lists.pharo.org

[Pharo-project] problem parsing XML

by Usman Bhatti

I am trying to parse XML files with rest APIs but I am getting an error due to the absence of this classVariable: NameStartChars. I could also reproduce this error with this pharo cast from Laurent where he tries to parse Picasa XML. http://www.pharocasts.com/2010/02/rest-xml-parsing-and-photos.html To reproduce the error, execute these snippets: Gofer new repository: 'http://ss3.gemstone.com/ss/xmlsupport'; package: 'Collections-BitmapCharacterSet'; package: 'Collections-OrderPreservingDictionary'; package: 'ConfigurationOfXMLSupport'; package: 'Pastell'; package: 'XML-Parser'; package: 'XML-Tests-Parser'; load Gofer new squeaksource: 'XMLSupport'; package: 'XML-Parser'; squeaksource: 'Pharocasts'; package: 'Picasa'; load. |photos| photos:=PicasaAPI new searchPhotos: 'miles+davis' maxResults: 3. PhotoWall new viewPhotos: photos. The problem is that the variable is used before being initialized. I'll see if I can produce a fix. regards, Usman

June 9, 2012

[Pharo-project] [update 2.0] #20118

by StÃ©phane Ducasse

20118 ----- - Issue 6038: ProtoObject should NOT implement #rehash. Thanks Mariano Martinez-Peck. :) http://code.google.com/p/pharo/issues/detail?id=6038

June 9, 2012

Re: [Pharo-project] What can be negative regarding timezones with date-related objects?

by Sven Van Caekenberghe

On 09 Jun 2012, at 14:24, Mariano Martinez Peck wrote: > The seconds/nanoseconds are always positive when normalized. > > Are you sure? > I have just changed (for testing) to this: > > DateAndTime localTimeZone: (TimeZone timeZones detect: [:tz | tz abbreviation = 'EST']). > > And now if I do: > > DateAndTime now offset asSeconds ----> -18000 The seconds/nanoseconds in DateAndTime itself are like that, the TZ offset can be positive and negative: http://en.wikipedia.org/wiki/Timezone <<Most of the 40 time zones on land are offset from Coordinated Universal Time (UTC) by a whole number of hours (UTCâ12 to UTC+14), but a few are offset by 30 or 45 minutes.>>

June 9, 2012

Re: [Pharo-project] thinking about another commit process

by StÃ©phane Ducasse

On Jun 9, 2012, at 2:36 PM, StÃ©phane Ducasse wrote: > Hi guys > > I would really like to see if we cannot have another way to integrate change in the system. A more open one. > > Now we have Ulyss the monkey and a bunch of ruby scripts that can really help us. I will sit with esteban and benjmain > when ben is back to see but it is just one part of the problem. > > With esteban we were working on using metacello to maintain/evolution Pharo, i.e. recursive management of configurationOf. > Now I would really like to see how we be faster too. > > I do not know how the squeak trunk is working once the packages are publish in trunk. > > But I would like to have a process where commiters can push in a head (special repos) and that the system integrate itself (modulo that there is no conflicts), i.e. > create new configurations and all the restâ¦. > > What do you think? in fact we could just have a queue where we say that a slice is ok and the system does it for us. Because this is still important that we can have a look at code. > > Setf

June 9, 2012

[Pharo-project] [update 2.0] #20117

by StÃ©phane Ducasse

20117 ----- - Issue 6024: Change SystemChangeNotifier subscriptions step 1. Thanks Guillermo Polito. So cool to have you with us. I like your systematic attitude. :) http://code.google.com/p/pharo/issues/detail?id=6024 Stef

June 9, 2012

[Pharo-project] thinking about another commit process

by StÃ©phane Ducasse

Hi guys I would really like to see if we cannot have another way to integrate change in the system. A more open one. Now we have Ulyss the monkey and a bunch of ruby scripts that can really help us. I will sit with esteban and benjmain when ben is back to see but it is just one part of the problem. With esteban we were working on using metacello to maintain/evolution Pharo, i.e. recursive management of configurationOf. Now I would really like to see how we be faster too. I do not know how the squeak trunk is working once the packages are publish in trunk. But I would like to have a process where commiters can push in a head (special repos) and that the system integrate itself (modulo that there is no conflicts), i.e. create new configurations and all the restâ¦. What do you think? Setf

June 9, 2012

Re: [Pharo-project] What can be negative regarding timezones with date-related objects?

by Nicolas Cellier

2012/6/9 Sven Van Caekenberghe <sven(a)beta9.be>: > Mariano, > > In normal use, offsets can be negative, yes. > But in theory, the JDN could be negative as wel, before -4700 ;-) > The seconds/nanoseconds are always positive when normalized. > That is how I understand it. > > Sven > > PS: nanoseconds and even seconds in the offset are a joke, there are no such timezones. Oh that's because those stupid administrators did not let an engineer invent the smooth DST ;) (one fraction of seconds every day instead of one hour every 6 months). Nicolas > > On 09 Jun 2012, at 12:28, Mariano Martinez Peck wrote: > >> Hi guys. Imagine in Fuel I am serializing date/time-related objects sending these messages: >> >> aDate julianDayNumber. >> aDateAndTime julianDayNumber. >> aDateAndTime nanoSecond. >> aDateAndTime secondsSinceMidnight. >> aDateAndTime offset asSeconds. >> aDateAndTime offset nanoSeconds. >> aDuration asSeconds. >> aDuration nanoSeconds. >> aTime asSeconds. >> aTime nanoeSecond. >> >> which of those things could answer negative numbers? because once I remember in my image everything was positive, but in other timezone I think "offset asSeconds" and "offset nanoSeconds" were negative in DateAndTime. >> >> thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com > >

June 9, 2012

Re: [Pharo-project] What can be negative regarding timezones with date-related objects?

by Mariano Martinez Peck

On Sat, Jun 9, 2012 at 12:44 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Mariano, > > In normal use, offsets can be negative, yes. > But in theory, the JDN could be negative as wel, before -4700 ;-) > The seconds/nanoseconds are always positive when normalized. > Are you sure? I have just changed (for testing) to this: DateAndTime localTimeZone: (TimeZone timeZones detect: [:tz | tz abbreviation = 'EST']). And now if I do: DateAndTime now offset asSeconds ----> -18000 > That is how I understand it. > > Sven > > PS: nanoseconds and even seconds in the offset are a joke, there are no > such timezones. > > On 09 Jun 2012, at 12:28, Mariano Martinez Peck wrote: > > > Hi guys. Imagine in Fuel I am serializing date/time-related objects > sending these messages: > > > > aDate julianDayNumber. > > aDateAndTime julianDayNumber. > > aDateAndTime nanoSecond. > > aDateAndTime secondsSinceMidnight. > > aDateAndTime offset asSeconds. > > aDateAndTime offset nanoSeconds. > > aDuration asSeconds. > > aDuration nanoSeconds. > > aTime asSeconds. > > aTime nanoeSecond. > > > > which of those things could answer negative numbers? because once I > remember in my image everything was positive, but in other timezone I think > "offset asSeconds" and "offset nanoSeconds" were negative in DateAndTime. > > > > thanks! > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

June 9, 2012

Re: [Pharo-project] recompiling class

by Marcus Denker

On Jun 9, 2012, at 8:26 AM, S Krish wrote: > > > Can we do this in Pharo: > > "in Java, the computation of numeric offsets for instance elds in memory is done by > the run-time system. This permits updating a class with new instance elds or methods without > affecting existing code. In other words, it is possible to run an existing bytecode file for a subclass > after updating and recompiling the class, but without recompiling the subclass." Hello, In Smalltalk, not only *new* instances get the changed class layout, but *all* existing ones are migrated. There is always just one version of a class in the system, all instances are of that version. Thus, if you add a instvar in a superclass, the iVar offsets of the subclasses have to be fixed. Right now this is done by recompiling the all subclasses, but you could be much more intelligent: filter for those methods that actually reference ivars and then don't recompile but just change the offset. This "just" is more difficult than it seems: changing an offset can mean that the bytecode needed is larger (2 instead of 1), and that then means jump offsets need to be changed. Which in turn can mean that the larger jump needs more bytecode, too.. So in practice, the best is to decompile to an Intermediate Representation that is at the level of bytecode, yet abtracts away jumps and the decision of which bytecode exactly it used. For the backend of Opal, I did some crude benchmark for Martin this week: Decompiling to IR and re-generating of all methods in Morph that access iVars takes 0.8 seconds... We will add the IR backend to 2.0 soon and the new ClassBuilder will use it. But in general, it would be nice to late-bind the offsets and just use names in the representation that a method is saved in. Marcus -- Marcus Denker -- http://marcusdenker.de

June 9, 2012

Re: [Pharo-project] What can be negative regarding timezones with date-related objects?

by Sven Van Caekenberghe

So you want the smallest possible binary encoding ? seconds between: 0 and: SecondsInDay (86400) nanoseconds between: 0 and: (10 riasedTo: 9) - 1 jdn is unlimited, how many years do you want to count ? the offset duration cannot be more than 24h I guess. On 09 Jun 2012, at 13:25, Mariano Martinez Peck wrote: > On Sat, Jun 9, 2012 at 12:44 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Mariano, > > In normal use, offsets can be negative, yes. > But in theory, the JDN could be negative as wel, before -4700 ;-) > The seconds/nanoseconds are always positive when normalized. > That is how I understand it. > > > Ok, now the other question is if they all need 32 bits integer or if they can ALWAYS fit in something smaller. > > > Sven > > PS: nanoseconds and even seconds in the offset are a joke, there are no such timezones. > > On 09 Jun 2012, at 12:28, Mariano Martinez Peck wrote: > > > Hi guys. Imagine in Fuel I am serializing date/time-related objects sending these messages: > > > > aDate julianDayNumber. > > aDateAndTime julianDayNumber. > > aDateAndTime nanoSecond. > > aDateAndTime secondsSinceMidnight. > > aDateAndTime offset asSeconds. > > aDateAndTime offset nanoSeconds. > > aDuration asSeconds. > > aDuration nanoSeconds. > > aTime asSeconds. > > aTime nanoeSecond. > > > > which of those things could answer negative numbers? because once I remember in my image everything was positive, but in other timezone I think "offset asSeconds" and "offset nanoSeconds" were negative in DateAndTime. > > > > thanks! > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 9, 2012