- Pharo-dev - lists.pharo.org

[Pharo-project] RMLL anyone?
by Hilaire Fernandes May 14, 2011

May 14, 2011

I will be there at Strasbourg from 9 to 14 of Jully - http://www.rmll.info Any Pharoer is joining? Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

2 4

[Pharo-project] We are still small, don't worry
by Mariano Martinez Peck May 14, 2011

May 14, 2011

Taking the latest PharoCore 1.3 and doing "ScriptLoader new cleanUpForProduction" (mostly cleanUps and tests removal ) Gives me a 6.9 MB image. So we are quite good. Cheers -- Mariano http://marianopeck.wordpress.com

2 1

Re: [Pharo-project] Help "migrating" from classic streams to XStreams
by mkobetic＠gmail.com May 13, 2011

May 13, 2011

"Mariano Martinez Peck"<marianopeck(a)gmail.com> wrote: > 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. I'd also recommend generic wrapper for any kind of Xtream rather than subclassing specific terminal. In VW the usual way to create the classic streams is via #readStream or #writeStream, so I'd add something like: XTReadStream>>readStream ^XTClassicReadStream on: self XTWriteStream>>writeStream ^XTClassicWriteStream on: self The "classic" guys would then implement the classic API by invoking Xtreams API on their source/destination. You can even subclass those from the classic ReadStream and WriteStream to possibly inherit some behavior and only implement some core part of the protocol. > 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: It's not as simple, there can be subtle differences. For example in VW it should be something like: next: anInteger ^[ source read: anInteger ] on: Incomplete do: [ :incomplete | IncompleteNextCountError new parameter: incomplete count; raiseRequest ] > nextString -> ?? > next -> get Again, in VW it would be more like: get ^[ source get ] on: Incomplete do: [ :incomplete | EndOfStreamNotification raiseRequest ] > nextWord -> ?? For the specialized element types (Number, String) you can pretty much copy the classic implementations (or even inherit them). Alternatively they seem to fall into a category that we call "interpreting" in Xtreams. What we have is primarily focused on interpreting bytes as various C-types (short, long, float, double,....) for which we have convenient primitives in VW, but the concept can certainly be extended further (the interpretation definitions are pluggable). Unfortunately this part wasn't ported yet from VW. For quick overview you can peek at the end of http://code.google.com/p/xtreams/wiki/Transforms. There's also general marshaling stream available on VW side (built on top of the interpreting streams) which might be helpful example of how one can approach this type of problem with Xtreams. HTH, Martin

1 0

Re: [Pharo-project] Adding "Extended Search" to OB context menu
by Lukas Renggli May 13, 2011

May 13, 2011

Sure, that can be done. The point is that the RB code menu is fully implemented in OB now. Previously OB just used the menu provided by Pharo, what caused all kinds of problems. "Method source with it" was never an operation backed by OB. Lukas On 9 May 2011 11:46, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi Lukas, > > do you think it would be possible to use what is currently selected in > the code pane to set the default value of the 'Refactor -> Search > code' window? > > > ---------- Forwarded message ---------- > From: Mariano Martinez Peck <marianopeck(a)gmail.com> > Date: Mon, May 9, 2011 at 10:56 AM > Subject: Re: [Pharo-project] Adding "Extended Search" to OB context menu > To: Pharo-project(a)lists.gforge.inria.fr > > >> Have you tried 'Refactor -> Search code' ? > > Thanks Damien. But that's something completely different. What I want > to do is to select text, right button, method source with it. That's > all. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > -- Lukas Renggli www.lukas-renggli.ch

2 3

Re: [Pharo-project] http://source.lukas-renggli.ch seems down?
by Marcus Denker May 13, 2011

May 13, 2011

On May 13, 2011, at 11:08 PM, Alexandre Bergel wrote: > Can it be restarted please? > The problem is that the network operator is down... see http://code.google.com/p/pharo/issues/detail?id=4218 We should really t hink hard about redundancy... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] http://source.lukas-renggli.ch seems down?
by Alexandre Bergel May 13, 2011

May 13, 2011

Can it be restarted please? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] SqueaSource is Down
by Marcus Denker May 13, 2011

May 13, 2011

... and they changed the passwd so I can not do anything. I feel very unprofessional now. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 4

[Pharo-project] [COTDC] 63 - MimeConverter
by laurent laffont May 13, 2011

May 13, 2011

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

1 1

Re: [Pharo-project] Helvetia... in Squeak
by Lukas Renggli May 13, 2011

May 13, 2011

Hi Frank, See my answers below inbetween your mail: > I've been playing around trying to get Helvetia working in Squeak. It's... > not going well. So I thought I'd try get it working in Pharo, so I could > play around with Helvetia - the point of the exercise - rather than futzing > with porting issues. I suggest that you download the one-click distribution from http://scg.unibe.ch/research/helvetia or the image from my build server (they should be identical). Loading the code manually doesn't work at the moment, because RB, OB, eCompletion and the other dependencies evolved in the meantime and are not compatible with Pharo 1.1.1 anymore. > Now I've tried loading Helvetia into a Pharo 1.1.1 image (old, I know, but > Helvetia says that it wants a 1.1 image), but things don't work too well - I > have issues like OBPluggableShoutTextMorph not understanding #setText:, > leaving me unable to open an omnibrowser. "Browser open" still works, but of > course senders-of and implementors-of are all smashed for the > afore-mentioned reason. Helvetia only works in Pharo 1.1.1 images with the dependencies that were available at that time. > Now I see you have Hudson build scripts for Helvetia, so clearly you've not > abandoned the project, so how do you do things? What base image do you use? > A Pharo 1.3? The builds are not running anymore. Helvetia is based on Pharo 1.1.1. I don't have the time to maintain the codebase. > If/when I get it working, would you be open to the idea of me working to > separate Helvetia's dependencies on things like Polymorph, OB, etc. so I can > use Helvetia in Squeak? Helvetia is all about integrating with tools, which means not only the compiler but also the editors, syntax highlighting, code completion, refactorings, etc. Moving Helvetia from Pharo 0.9 to Pharo 1.1 was a lot of work, because the loader needs to replace the compiler and introduce all kinds of subtle hooks into the running system. I doubt it is possible to get a working version of Helvetia in Squeak without a significant amount of work. After all, only outdated or forked versions of RB, OB, eCompletion, Shout, ... work in Squeak. Also --- and that would be probably the fist and most important step --- you would need to make PetitParser, RB, AST-Compiler, and QuasiQuote work in Squeak. These are the base compilation-related packages required by Helvetia. HTH, Lukas -- Lukas Renggli www.lukas-renggli.ch

3 5

Re: [Pharo-project] What we do with: "Embed source code for methods which get uninstalled from their classes" ???
by Marcus Denker May 13, 2011

May 13, 2011

On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote: > > 1) have a fast/normal recompileAll > 2) not to loose source code > > If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this. > I think we should roll back the change for now... All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even on last year's cell phone 20 times larger than our complete system...) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

7 7