- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Help "migrating" from classic streams to XStreams

by Nicolas Cellier

And concerning nextNumber nextString etc... this supposes a certain format, we can't guess. If you have a DSL for your data with known grammar, you could try a PEG parser. Otherwise, if your data are in a classical Smalltalk format in ASCII, you could use Number readFrom: yourXTCompatibilityReadStream. Otherwise if you have a specific binary encoded data, it's up to you... Nicolas 2011/5/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Of course, another way is simply to define a > *XTream-classic-API-compatibility in upper level XTReadStream, but > that's less fun :) > > Nicolas > > 2011/5/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Don't do it exclusively for file, but do it for every XTream >> One way to do it would be with a wrapper. >> I mean create a new subclass of XTReadStream, say >> XTCompatibilityReadStream Â implement the compatibility methods you >> want. >> Same for WriteStream. >> You'll have to define a few XTream messages too that delegates to the >> source/destination >> >> blah >> Â Â ^source blah >> >> foo >> Â Â ^destination foo >> >> >> Then define something like >> >> XTReadStream>>classicalStreamAPI >> Â Â ^XTCompatibilityReadStream on: self >> >> My 2c. >> >> Nicolas >> >> 2011/5/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary >>> serializer similar to Parcels. More info in >>> http://rmod.lille.inria.fr/web/pier/software/Fuel >>> >>> For the moment, we are using the "classic" streams we want to give it a try >>> to XStreams. My knowledge on streams is very little, so if someone can give >>> me a hint I would really appreciate it. >>> What I want to do right now is an adaptor of XStreams to classic stream. I >>> mean, I want to create custom subclasses of XTFileWriteStream and >>> XTFileReadStream that implements the same API from classic streams that we >>> use in Fuel. And the implementations of such methods will do just a "self >>> something" where something is the way of doing that in XStreams. >>> >>> So, the following is the protocol we use in Fuel for streams, and what I >>> would love to know is the associated way to do it it XStreams. The left is >>> classic streams, and after the "->" it is XStreams: >>> >>> Reading: >>> >>> nextNumber: -> ?? >>> nextPutAll: -> write: >>> nextStringPut: -> ?? >>> nextPut:Â -> put: >>> nextNumber:put: -> ?? >>> nextWordPut: -> ?? >>> >>> Writing: >>> >>> nextNumber: -> ?? >>> next:Â -> read: >>> nextString -> ?? >>> nextÂ -> get >>> nextWord -> ?? >>> >>> Thanks a lot in advance, >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >

May 13, 2011

[Pharo-project] [COTDC] 64 - UrlArgumentList

by laurent laffont

Today: UrlArgumentList 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

May 13, 2011

Re: [Pharo-project] Help "migrating" from classic streams to XStreams

by Nicolas Cellier

Of course, another way is simply to define a *XTream-classic-API-compatibility in upper level XTReadStream, but that's less fun :) Nicolas 2011/5/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Don't do it exclusively for file, but do it for every XTream > One way to do it would be with a wrapper. > I mean create a new subclass of XTReadStream, say > XTCompatibilityReadStream Â implement the compatibility methods you > want. > Same for WriteStream. > You'll have to define a few XTream messages too that delegates to the > source/destination > > blah > Â Â ^source blah > > foo > Â Â ^destination foo > > > Then define something like > > XTReadStream>>classicalStreamAPI > Â Â ^XTCompatibilityReadStream on: self > > My 2c. > > Nicolas > > 2011/5/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary >> serializer similar to Parcels. More info in >> http://rmod.lille.inria.fr/web/pier/software/Fuel >> >> For the moment, we are using the "classic" streams we want to give it a try >> to XStreams. My knowledge on streams is very little, so if someone can give >> me a hint I would really appreciate it. >> What I want to do right now is an adaptor of XStreams to classic stream. I >> mean, I want to create custom subclasses of XTFileWriteStream and >> XTFileReadStream that implements the same API from classic streams that we >> use in Fuel. And the implementations of such methods will do just a "self >> something" where something is the way of doing that in XStreams. >> >> So, the following is the protocol we use in Fuel for streams, and what I >> would love to know is the associated way to do it it XStreams. The left is >> classic streams, and after the "->" it is XStreams: >> >> Reading: >> >> nextNumber: -> ?? >> nextPutAll: -> write: >> nextStringPut: -> ?? >> nextPut:Â -> put: >> nextNumber:put: -> ?? >> nextWordPut: -> ?? >> >> Writing: >> >> nextNumber: -> ?? >> next:Â -> read: >> nextString -> ?? >> nextÂ -> get >> nextWord -> ?? >> >> Thanks a lot in advance, >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >

May 13, 2011

Re: [Pharo-project] Need help with 1.3 Full Image

by laurent laffont

On Fri, May 13, 2011 at 9:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > Thanks to push Marcus. > > Yes! > > > > What I'm thinking about is that it's a lot of energy to fix stuff about > things we don't know. I rarely succeed in fixing something new (but I learn > a little more every day :). > > > > I tried to organize a Pharo sprint over internet / IRC for Pharo 1.2 but > there was only Guillermo and me (cool indeed). But I continue to think it's > a good way to fusion energy and more fun to fix stuff together (not alone). > > > > Fixing bugs is a good way to learn, but easier with other people. So can > we have some virtual sprints over Skype or IRC ? > > yes this would be fun. > I think that we should have more virtual meeting to talk about key actions. > Another way is to create the "Fix Of The Day Contest", one day, one fix :) Laurent.

May 13, 2011

Re: [Pharo-project] [COTDC] 63 - MimeConverter

by laurent laffont

On Thu, May 12, 2011 at 8:40 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: MimeConverter > I'm the base class for converting some data from a MIME type to another. Subclasses should implement #mimeDecode and #mimeEncode. Laurent. > > > 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 >

May 13, 2011

Re: [Pharo-project] Help "migrating" from classic streams to XStreams

by Nicolas Cellier

Don't do it exclusively for file, but do it for every XTream One way to do it would be with a wrapper. I mean create a new subclass of XTReadStream, say XTCompatibilityReadStream implement the compatibility methods you want. Same for WriteStream. You'll have to define a few XTream messages too that delegates to the source/destination blah ^source blah foo ^destination foo Then define something like XTReadStream>>classicalStreamAPI ^XTCompatibilityReadStream on: self My 2c. Nicolas 2011/5/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary > serializer similar to Parcels. More info in > http://rmod.lille.inria.fr/web/pier/software/Fuel > > For the moment, we are using the "classic" streams we want to give it a try > to XStreams. My knowledge on streams is very little, so if someone can give > me a hint I would really appreciate it. > What I want to do right now is an adaptor of XStreams to classic stream. I > mean, I want to create custom subclasses of XTFileWriteStream and > XTFileReadStream that implements the same API from classic streams that we > use in Fuel. And the implementations of such methods will do just a "self > something" where something is the way of doing that in XStreams. > > So, the following is the protocol we use in Fuel for streams, and what I > would love to know is the associated way to do it it XStreams. The left is > classic streams, and after the "->" it is XStreams: > > Reading: > > nextNumber: -> ?? > nextPutAll: -> write: > nextStringPut: -> ?? > nextPut:Â -> put: > nextNumber:put: -> ?? > nextWordPut: -> ?? > > Writing: > > nextNumber: -> ?? > next:Â -> read: > nextString -> ?? > nextÂ -> get > nextWord -> ?? > > Thanks a lot in advance, > > > -- > Mariano > http://marianopeck.wordpress.com > >

May 13, 2011

Re: [Pharo-project] Need help with 1.3 Full Image

by StÃ©phane Ducasse

> Thanks to push Marcus. Yes! > > What I'm thinking about is that it's a lot of energy to fix stuff about things we don't know. I rarely succeed in fixing something new (but I learn a little more every day :). > > I tried to organize a Pharo sprint over internet / IRC for Pharo 1.2 but there was only Guillermo and me (cool indeed). But I continue to think it's a good way to fusion energy and more fun to fix stuff together (not alone). > > Fixing bugs is a good way to learn, but easier with other people. So can we have some virtual sprints over Skype or IRC ? yes this would be fun. I think that we should have more virtual meeting to talk about key actions.

May 13, 2011

Re: [Pharo-project] Need help with 1.3 Full Image

by laurent laffont

On Fri, May 13, 2011 at 9:23 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > In the past, the build of the Full/Dev image was broken most of the time, > leading to bugs being discovered > late, bugs not fixed while everyone is using the system and getting bitten > by them... > > Now the Dev/Full image exactly is a such a thing that has no bottleneck: > it's just some load scripts > loading third party tools/libs. Just editing scripts and bug the > maintainers. Nothing else to do. > > So it should be fixed far faster and much easier than Core, as it can be > done in parallel? Right? Right? > Wrong. The only person doing anyting is Mariano... (and me, I fixed 1.2 > Full after is was broken an *astonishing* > 23 *days* !!!!) > > I personally think this really wants to tell us something, but that's just > me. > > So what we need is people who look at this list: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3-DevImage > > And *fix* the issues. Fast. I can not. Really not. > > Thanks to push Marcus. What I'm thinking about is that it's a lot of energy to fix stuff about things we don't know. I rarely succeed in fixing something new (but I learn a little more every day :). I tried to organize a Pharo sprint over internet / IRC for Pharo 1.2 but there was only Guillermo and me (cool indeed). But I continue to think it's a good way to fusion energy and more fun to fix stuff together (not alone). Fixing bugs is a good way to learn, but easier with other people. So can we have some virtual sprints over Skype or IRC ? Laurent > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

May 13, 2011

[Pharo-project] Help "migrating" from classic streams to XStreams

by Mariano Martinez Peck

Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary serializer similar to Parcels. More info in http://rmod.lille.inria.fr/web/pier/software/Fuel For the moment, we are using the "classic" streams we want to give it a try to XStreams. My knowledge on streams is very little, so if someone can give me a hint I would really appreciate it. What I want to do right now is an adaptor of XStreams to classic stream. I mean, I want to create custom subclasses of XTFileWriteStream and XTFileReadStream that implements the same API from classic streams that we use in Fuel. And the implementations of such methods will do just a "self something" where something is the way of doing that in XStreams. So, the following is the protocol we use in Fuel for streams, and what I would love to know is the associated way to do it it XStreams. The left is classic streams, and after the "->" it is XStreams: *Reading:* nextNumber: -> ?? nextPutAll: -> write: nextStringPut: -> ?? nextPut: -> put: nextNumber:put: -> ?? nextWordPut: -> ?? *Writing: * nextNumber: -> ?? next: -> read: nextString -> ?? next -> get nextWord -> ?? Thanks a lot in advance, -- Mariano http://marianopeck.wordpress.com

May 13, 2011

Re: [Pharo-project] Need help with 1.3 Full Image

by StÃ©phane Ducasse

We will soon integrate RBEngine, AST, into core so you will have less to maintain. Now for me, what is important is not the number of bugs but the ratio of new things/bugs and I think that it is pretty low when we take into account all the changes and improvements we did. Having a better textEditor is important. Now this is ok that you do not have time, we understand that too, I know what is to move, get a new job and be credible (I did that twice over the last 5 years) but then after we suffer that you start to complain after the release when we give 3 months of RC candidates. Stef On May 13, 2011, at 6:41 PM, Lukas Renggli wrote: > Hi Stef, > >> uh? what are these bugs? > > From the top of my head these are all bugs that appeared in the past > weeks and that were not present in Pharo 1.1: > > - temps and method selector changes that disappear and that are not > logged in the changes file > - text formatting that vanishes from larger texts > - mouse selection that is broken > - various OB bugs, such as broken smart chars, scroll bar, tests, text > search, ... > >> I'm really surprised. I'm also surprised that you say that when you did not >> even tried to port your tools to 1.2 during the release candidate phase and that people >> tried and failed and you started to port your tool when 1.2 was released. >> You were undermining our process sadly. > > I was moving to a different place, starting with a new job, and > learning new things. > > I don't have the energy and interest to constantly run after the > latest releases. I want to use something stable to work with in the > little spare time I have, and not be constantly disturbed by new > problems that show up because something subtle changed. For me Pharo > 1.2.x will be the last version until something really compelling shows > up ... > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

May 13, 2011