Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
On Feb 14, 2010, at 6:37 AM, Igor Stasenko wrote:
> On 12 February 2010 15:09, Lukas Renggli wrote:
>>> It is interesting to note that of course, after this was added to 3.9,
>>> there was
>>> someone *very hard* arguing that adding Pragmas was a very dumb idea...
>>>
>>> Who that person was is left as an exercise to the reader of course ;-)
>>
>> Hint: FFI has its own proprietary hardcoded pragma format. It
>> unnecessary complicates the compiler even when not loaded. Not to
>> mention that it breaks all tools that have their own parser, such as
>> RB for example.
>>
>
> I'd like to discuss, what changes to compiler we may introduce to allow FFI
> to handle pragmas in non-intrusive manner.
>
Very simple: FFI just needs to use the pragmas as introduces in 3.9, than
remove all
knowledge about FFI from the Compiler. Problem solved. Isn't that beautiful?
< cdecl: void 'InvalRect' ( MacRect ) module: 'InterfaceLib'>
of that would be changed so that the stuff inside the <> would be a standard
Smalltalk Message expression, problem solved.
to illustrate... using the SMaCC grammar of the NewCompiler (a bit simplified)
as extendend for Pragmas, Primitives and FFI by
Mathiue Suen.
A method in Squeak has Pragmas:
Method:
| MethodPattern Temporaries Pragmas Statements {#methodTempsPragma:};
So they are difined like this (we can have multiple ones):
Pragmas:
"<" PragmaMessage ">"
{#pragma:}
| Pragmas "<" PragmaMessage ">"
{#pragmas:}
So it's quite simple: there is one message expression inside... simple. But
there is FFI. Primitives are
there, too, but that's not really a problem: they fit in the Pragmas.
primitive: 15 is a valid message in Smalltalk.
(Math did the gramar for primitives to have nice error messages, but that's
not needed)
PragmaMessage:
Apicall
{#messagePragma:}
| Primitive
{#messagePragma:}
| MessagePragma
{#messagePragma:};
How Primitive and MessagePragma are done is not important. But we need Gramar
rules just to be able to parse
FFI:
Apicall:
TypeCall ExternalType IndexName "(" ParameterApicall
{#externalCall:}
| TypeCall ExternalType IndexName "(" ParameterApicall
"module:" {#externalModuleCall:};
IndexName:
{#externalFunction:}
|
{#externalIndex:};
TypeCall:
"apicall:"
{#callConvention:}
| "cdecl:"
{#callConvention:};
ParameterApicall:
ExternalType
{#parameterExtCall:}
| ParameterApicall ExternalType
{#parametersExtCall:};
ExternalType:
{#externalType:}
|"*"
{#externalTypePointer:};
And this is *always* in the Grammar. Even when FFI is not loaded! (a nice
example where our simple notion of
modularity brakes down completely).
No the solution here is simple: a small trivial modification to FFI to use the
Evil Pragmas as introduced by the Dumb
People (tm) in 3.9:
< cdecl: 'void InvalRect ( MacRect )' module: 'InterfaceLib'>
or *whatever*. just something that is a valid Smalltalk message expression...
can't be hard, can it?
Ah. And and about "notion of modularity"... of course the problem "how can I
extend the language from
my package without having to spread code over the parser, compiler, debugger,
browser..." is intellectually
an interesting one. And, oh, we are payed for finding these kind of Problems
and especially solving these Problems
in a way that goes beyond of just doing a pragmatic and simple solution (aka
what I described here).
(They call it "Academic Research". Involves mostly a programming language
called TeX and can be very boring at times
but it's complementary to the practical world... in a very interesting way).
And int his context the result is, of course, tataaa: Lukas' Helvetia:
http://scg.unibe.ch/research/helvetia/languageboxes
See? So *everything* fits together... research and non-research, problems and
solutions (on multiple levels),
progress in the small and the large!
Marcus
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
___
Pharo-project mailing list
Phar
Re: [Pharo-project] Pharo changing the game
On 13 February 2010 03:12, Eagle Offshore wrote: > I think the really tragic thing is that nothing in Smalltalk remains stable. > Hehe.. and i love smalltalk exactly because of that! Let's not forget that it is hardware, which called 'an early frozen software'. Smalltalk evolves, because IT CAN. ;) But sure, its not hard to find a stable things nowadays - see java with its 'final' stuff :) > It would seem to me that in a language that has been around thirty years or > so that core data types like numbers, dates, times, and (hopefully, although > adoption of unicode was disruptive) strings would be the same across all the > dialects. > > By now, there should be some chunks of the system that we can deem fully > mature and then learn to LEAVE ALONE. > > The 16rff issue is a fine example of an absolutely stupid incompatibility. > > Just my $.04 > > -Todd Blanchard > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GoferApiTest failing (WinXP)
> running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see > GoferApiTest>>#testSubDirectoryRepository failing. Are you sure that you use the latest Gofer code, because I think I fixed that a while back. > It could be fixed by changing > > MCSubDirectoryRepository>>#description > > + ^ directory pathName, FileDirectory slash , '*' > - ^ directory pathName, '/*' > > The current implementation works because '/' and '\' both are valid path > separators on windows. Assuming '/' as path delimiter would cause trouble with > MacFileDirectory - but that might be obsolete anyway. > So may be the test is too strict? I bet that breaks the tests on all platforms other than Windows. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
>>> It is interesting to note that of course, after this was added to 3.9, >>> there was >>> someone *very hard* arguing that adding Pragmas was a very dumb idea... >>> >>> Who that person was is left as an exercise to the reader of course ;-) >> >> Hint: FFI has its own proprietary hardcoded pragma format. It >> unnecessary complicates the compiler even when not loaded. Not to >> mention that it breaks all tools that have their own parser, such as >> RB for example. >> > > I'd like to discuss, what changes to compiler we may introduce to allow FFI > to handle pragmas in non-intrusive manner. > I suppose something, like registration mechanism for compiler, where > any external package can > register and provide own handler(s) for pragmas. > Then, of course, an Encoder should have a public API, which would > allow such handlers to add/change literals > and method header. > > We already having at least another use of pragmas - preferences. It's > also could use same mechanism which can > be used to notify a preferences system about appearance of new or > removal existing preferences as a result of method compilation. In fact we had that in Squeak 3.9 and early Pharo versions. I even wrote code that adapted this mechanism for FFI, but the FFI maintainer insisted on sticking with his compiler hacks. The idea was that you could add methods with a specific pragma to one of the compiler classes (I don't remember which one). There was also one such method for each of the Smalltalk primitives currently supported (#primitive:, 3primitive:module:, ...). When encountering a pragma in the source code the compiler would check if this was a compiler-pragma with the same name defined and perform that method. In the case of the primitive the compiler would change the compile method to use the configured primitive. A very strait forward use of pragmas. However the functionality that made compiler pragmas and primitives extensible is gone today even in Pharo. For reasons unknown to me Eliot removed all the code when he added the closure support. Back to hacking and patching the compiler. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
On 12 February 2010 15:09, Lukas Renggli wrote: >> It is interesting to note that of course, after this was added to 3.9, there >> was >> someone *very hard* arguing that adding Pragmas was a very dumb idea... >> >> Who that person was is left as an exercise to the reader of course ;-) > > Hint: FFI has its own proprietary hardcoded pragma format. It > unnecessary complicates the compiler even when not loaded. Not to > mention that it breaks all tools that have their own parser, such as > RB for example. > I'd like to discuss, what changes to compiler we may introduce to allow FFI to handle pragmas in non-intrusive manner. I suppose something, like registration mechanism for compiler, where any external package can register and provide own handler(s) for pragmas. Then, of course, an Encoder should have a public API, which would allow such handlers to add/change literals and method header. We already having at least another use of pragmas - preferences. It's also could use same mechanism which can be used to notify a preferences system about appearance of new or removal existing preferences as a result of method compilation. > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo changing the game
It is not a code problem. It is a social/political problem. On Feb 13, 2010, at 1:52 AM, Stéphane Ducasse wrote: > Send code and it will be fixed in one hour. > > Stef > >> I think the really tragic thing is that nothing in Smalltalk remains stable. >> >> It would seem to me that in a language that has been around thirty years or >> so that core data types like numbers, dates, times, and (hopefully, although >> adoption of unicode was disruptive) strings would be the same across all the >> dialects. >> >> By now, there should be some chunks of the system that we can deem fully >> mature and then learn to LEAVE ALONE. >> >> The 16rff issue is a fine example of an absolutely stupid incompatibility. >> >> Just my $.04 >> >> -Todd Blanchard >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] GoferApiTest failing (WinXP)
Hello to everybody,
running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see
GoferApiTest>>#testSubDirectoryRepository failing.
It could be fixed by changing
MCSubDirectoryRepository>>#description
+ ^ directory pathName, FileDirectory slash , '*'
- ^ directory pathName, '/*'
The current implementation works because '/' and '\' both are valid path
separators on windows. Assuming '/' as path delimiter would cause trouble with
MacFileDirectory - but that might be obsolete anyway.
So may be the test is too strict?
I just started to follow this list and the Pharo project ('Recreational
programmer' btw. - thanks for the kind welcome message ;) ). Should I report
this? And if so: It is a MC issue, should it be reported using the Pharo
tracker
or somewere else?
Cheers, Christoph
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [ANN] HelpSystem (was ProfStef)
>I have implemented some authoring capabilities in ProfStefBrowser >to create new tutorials Yes, authoring capabilities would be cool to have. But first we have to find out what the content really should be and how it should be represented (simple text, markup, active morphs, ...) >Some kind of simple markup language to have for example links to other pages >or books, or to execute code snippets with a single mouse click Do you know the Squeak welcome workspace? It provided something like this - a Text could define "runs" to change style, color of text or even have clickable links with Smalltalk code behind - dont know if this is still possible in Pharo since parts of Morphic are removed. On the other hand it was Squeak only - hard to create from tyical documentation formats (text, HTML, ...) Maybe we could reactive code from "Scamper" (the Squeak web browser) for simple HTML like text styling. Using a subset of HTML as description would also allow us to publish the help contents on webpages later. I also remember a full webbrowser written in Smalltalk (VW). Meanwhile it is open source (MIT), see [1] ... so lets just reactivate it ;) We all have many ideas (like yours with the debugger) - but first I would like to see a minimal version for a help system: - provide help contents as simple ascii text (as it is now) - ability to jump from a tool to a specific page (like F1-help on Windows) we can use a simple unique key which is defined in HelpTopic already. - ability to define order of pages together with order of (sub)books With a minimal help tool (included in the dev-image) we can provide help to beginners and start documenting Pharo. As a second step we can work on better markup, authoring, active content ... However - the repo is open for any contribution... >NowIt is not clear for me the differences between HelpSystem and >ProfStef. "HelpSystem" is like a normal help system you know from Eclipse, KDE, Windows, ... It is more a reference/documentation kind of thing. "ProfStef" is an interactive tutorial usefull to teach things step by step. >Help system is new ? Yes, developed yesterday. >should they be merged? Hey, we just decoupled ... why merge again ;) Read [2] >when we should use one and when the other ? ProfStef is for an introduction (5min course) on Pharo or tools, an interactive tutorial to introduce Smalltalk or basic concepts. It is more "workspace" oriented. See Laurents comments. HelpSystem is more a general help system with a "browser" that should be available as a base framework so tools can provide help texts/contents to users. Bye T. [1] http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=true&printTitle=Im_back..._but_SWS_isnt&entry=3364012145 [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021782.html -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [ANN 1.1] pre-built core 1.1 #11208
http://gforge.inria.fr/frs/download.php/26404/PharoCore-1.1-11208-UNSTABLE.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11208
11208 - - Issue 1960: ExtendedNumberParser and Friend in Squeak should probably be packaged as separate Pharo package - Issue 1957: Cleanings Utilities tx JB :) - more tests for WeakRegistry - remove all senders of or:or:, or:or:or:, or:or:or:or: and or:or:or:or:or:. Add a deprecated message in each one. Remove the method or:or:or:or:or: Tx Jannik :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About String empty and others
On Feb 13, 2010, at 8:03 PM, Stéphane Ducasse wrote: > the only think is that the #() and '' will not be created all the time but in > the compile method literal frame. > Yes, right now it's created once per method... the compiler could easily make sure that it's shared globally. Marcus > Stef > > >> would the idea to be to rewrite every #() with Array empty? >> >> If that was the case could you get the compiler to do that as an >> optimization? I quite like the fact that #() is the empty array. it's >> nice and compact; quite aesthetic. >> >> cheers, >> Mike >> >> On Sat, Feb 13, 2010 at 11:06 AM, Stéphane Ducasse >> wrote: >>> Hi guys >>> >>> chris mueller proposed in squeak to have >>> >>> >>> Exception>>messageText >>> "Return an exception's message text." >>> + ^ messageText ifNil: [ String empty ]! >>> - >>> - ^messageText! >>> >>> - Added Array class>>#empty and String class>>#empty to provide >>> applications with >>> canonicalized instances of these oft-used objects; since they are embedded >>> as literals in the >>> CompiledMethod. >>> >>> === Diff against Collections-ar.304 === >>> >>> Item was added: >>> + - Method: Array class>>empty (in category 'instance creation') - >>> + empty >>> + "A canonicalized empty Array instance." >>> + ^ #()! >>> >>> Item was added: >>> + - Method: String class>>empty (in category 'instance creation') - >>> + empty >>> + "A canonicalized empty String instance." >>> + ^ ''! >>> >>> Item was removed: >>> - - Method: String>>asDefaultDecodedString (in category 'converting') >>> - >>> - asDefaultDecodedString >>> - >>> - ^ self >>> >>> >>> http://code.google.com/p/pharo/issues/detail?id=1961 >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About String empty and others
the only think is that the #() and '' will not be created all the time but in the compile method literal frame. Stef > would the idea to be to rewrite every #() with Array empty? > > If that was the case could you get the compiler to do that as an > optimization? I quite like the fact that #() is the empty array. it's > nice and compact; quite aesthetic. > > cheers, > Mike > > On Sat, Feb 13, 2010 at 11:06 AM, Stéphane Ducasse > wrote: >> Hi guys >> >> chris mueller proposed in squeak to have >> >> >> Exception>>messageText >> "Return an exception's message text." >> + ^ messageText ifNil: [ String empty ]! >> - >> - ^messageText! >> >> - Added Array class>>#empty and String class>>#empty to provide applications >> with >> canonicalized instances of these oft-used objects; since they are embedded >> as literals in the >> CompiledMethod. >> >> === Diff against Collections-ar.304 === >> >> Item was added: >> + - Method: Array class>>empty (in category 'instance creation') - >> + empty >> + "A canonicalized empty Array instance." >> + ^ #()! >> >> Item was added: >> + - Method: String class>>empty (in category 'instance creation') - >> + empty >> + "A canonicalized empty String instance." >> + ^ ''! >> >> Item was removed: >> - - Method: String>>asDefaultDecodedString (in category 'converting') >> - >> - asDefaultDecodedString >> - >> - ^ self >> >> >> http://code.google.com/p/pharo/issues/detail?id=1961 >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About String empty and others
On Feb 13, 2010, at 7:40 PM, Michael Roberts wrote: > would the idea to be to rewrite every #() with Array empty? no and this is a good question. For now I do not see what we learn. I'm not sure that these empty messages bring anything. besides one extra message. > If that was the case could you get the compiler to do that as an > optimization? I quite like the fact that #() is the empty array. it's > nice and compact; quite aesthetic. yes I will roll back some of the changes > > cheers, > Mike > > On Sat, Feb 13, 2010 at 11:06 AM, Stéphane Ducasse > wrote: >> Hi guys >> >> chris mueller proposed in squeak to have >> >> >> Exception>>messageText >> "Return an exception's message text." >> + ^ messageText ifNil: [ String empty ]! >> - >> - ^messageText! >> >> - Added Array class>>#empty and String class>>#empty to provide applications >> with >> canonicalized instances of these oft-used objects; since they are embedded >> as literals in the >> CompiledMethod. >> >> === Diff against Collections-ar.304 === >> >> Item was added: >> + - Method: Array class>>empty (in category 'instance creation') - >> + empty >> + "A canonicalized empty Array instance." >> + ^ #()! >> >> Item was added: >> + - Method: String class>>empty (in category 'instance creation') - >> + empty >> + "A canonicalized empty String instance." >> + ^ ''! >> >> Item was removed: >> - - Method: String>>asDefaultDecodedString (in category 'converting') >> - >> - asDefaultDecodedString >> - >> - ^ self >> >> >> http://code.google.com/p/pharo/issues/detail?id=1961 >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About String empty and others
would the idea to be to rewrite every #() with Array empty? If that was the case could you get the compiler to do that as an optimization? I quite like the fact that #() is the empty array. it's nice and compact; quite aesthetic. cheers, Mike On Sat, Feb 13, 2010 at 11:06 AM, Stéphane Ducasse wrote: > Hi guys > > chris mueller proposed in squeak to have > > > Exception>>messageText > "Return an exception's message text." > + ^ messageText ifNil: [ String empty ]! > - > - ^messageText! > > - Added Array class>>#empty and String class>>#empty to provide applications > with > canonicalized instances of these oft-used objects; since they are embedded as > literals in the > CompiledMethod. > > === Diff against Collections-ar.304 === > > Item was added: > + - Method: Array class>>empty (in category 'instance creation') - > + empty > + "A canonicalized empty Array instance." > + ^ #()! > > Item was added: > + - Method: String class>>empty (in category 'instance creation') - > + empty > + "A canonicalized empty String instance." > + ^ ''! > > Item was removed: > - - Method: String>>asDefaultDecodedString (in category 'converting') > - > - asDefaultDecodedString > - > - ^ self > > > http://code.google.com/p/pharo/issues/detail?id=1961 > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11207
11207 - - Issue 1959: Replace isSomething by is: # (starting) - Fix of parser 16rff now works - Deprecate digitValue: to use digitValueOf: ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont
> Which web page ?
>
> Laurent Laffont
>
>
>
> On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse <
> stephane.duca...@inria.fr> wrote:
>
>> laurent have a look in the network chapter of the new blue book
>> (collective book available on web page)
>> because I do not remember but you could find some snippets going in the
>> same sense.
>>
>> Stef
>>
>> On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
>>
>> > (SketchMorph fromStream:
>> > ('http://code.google.com/p/pharo/logo'
>> > asUrl retrieveContents contentStream)) openInWorld
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/
Stef
On Feb 13, 2010, at 3:59 PM, laurent laffont wrote:
> Which web page ?
>
> Laurent Laffont
>
>
> On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
> wrote:
> laurent have a look in the network chapter of the new blue book (collective
> book available on web page)
> because I do not remember but you could find some snippets going in the same
> sense.
>
> Stef
>
> On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
>
> > (SketchMorph fromStream:
> > ('http://code.google.com/p/pharo/logo'
> > asUrl retrieveContents contentStream)) openInWorld
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse wrote:
> laurent have a look in the network chapter of the new blue book (collective
> book available on web page)
> because I do not remember but you could find some snippets going in the
> same sense.
>
> Stef
>
> On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
>
> > (SketchMorph fromStream:
> > ('http://code.google.com/p/pharo/logo'
> > asUrl retrieveContents contentStream)) openInWorld
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11206
11206 - - Issue 1955: Parser should parse 16rff (part two) - Better association class comment - Issue 1929: Should check fasterKey and key - Issue 1942: Check allSubclassesDoGently: and friends ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
laurent have a look in the network chapter of the new blue book (collective
book available on web page)
because I do not remember but you could find some snippets going in the same
sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
> (SketchMorph fromStream:
> ('http://code.google.com/p/pharo/logo'
> asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
*I've found this in my mails:*
*
*
*
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
*Laurent Laffont
On Sat, Feb 13, 2010 at 3:08 PM, Stéphane Ducasse wrote:
> I like the idea of the scenario.
>
>XMLParser
>
> We really need more of such examples.
>
> Stef
>
>
> > Hi,
> >
> > I would like to record a screencast with the following scenario:
> > - search for pictures using Flickr web services,
> http://www.flickr.com/services/api/, XML-RPC response
> > - parse the XML to get pictures URL
> > - download pictures
> > - display them in a morphic GUI
> >
> > Which packages should I use to use Web services, parse XML, download
> pictures ?
> >
> > Is there existing apps / code which do this sort of things ?
> >
> > Thanks !
> >
> > Laurent Laffont
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
I like the idea of the scenario. XMLParser We really need more of such examples. Stef > Hi, > > I would like to record a screencast with the following scenario: > - search for pictures using Flickr web services, > http://www.flickr.com/services/api/, XML-RPC response > - parse the XML to get pictures URL > - download pictures > - display them in a morphic GUI > > Which packages should I use to use Web services, parse XML, download pictures > ? > > Is there existing apps / code which do this sort of things ? > > Thanks ! > > Laurent Laffont > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about NumberParser
ok let me know when this is ready and I will integrate them because I like the idea to be able to customize it. On Feb 13, 2010, at 12:34 PM, Nicolas Cellier wrote: > 2010/2/13 Stéphane Ducasse : >> Hi nicolas >> >> I like the idea to have an easy to customize parser number. >> Do you have a slice that I could integrate once your changes are done. >> Or show I go in squeak trunk and take the code? >> I imagine that we could then package FORTRAN and ExtendedNumberParser in a >> different package. >> >> http://code.google.com/p/pharo/issues/detail?id=1960 >> > > Changes should be very easy to pick. > FORTRANNumberParser is just a demonstrator and should find it's way > out of kernel image. > However, ExtendedNumberParser is designed for Kernel, for enhancing > String>>asNumber. > > Nicolas > >> Stef >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fraction>>adaptToScaledDecimal:andSend:
OK I remember that scaleddecimal was a problem and we decided to discard. Stef > 2010/2/13 Stéphane Ducasse : >> Hi nicolas >> >> I saw that you are working on squeak on Fraction and ScaledDecimal. >> How is it related to the change we discussed a while ago about Float? >> How squeak deals with the fact that scaledDecimal was not MIT (if I remember >> correctly)? >> I would like to avoid to diverge too quickly on numbers :) >> >> Stef > > Just putting Squeak to the level of Pharo :), > I probably took the coercion test from Pharo,can't remember. > Concerning license stuff, I'll wait announcement of 4.0, no hurry. > But sure, there is no reason to diverge on core. > > Nicolas > >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
2010/2/13 laurent laffont > Hi, > > I would like to record a screencast with the following scenario: > - search for pictures using Flickr web services, > http://www.flickr.com/services/api/, XML-RPC response > - parse the XML to get pictures URL > - download pictures > - display them in a morphic GUI > > Which packages should I use to use Web services, parse XML, download > pictures ? > > Is there existing apps / code which do this sort of things ? > > Sorry I cannot help you, but let me say that this particular example is VERY useful for "real applications". Having to parse XML and interact through webservices to another systems, is present in mostly current software projects. So, please..I hope you can do it and record it. Cheers Mariano > Thanks ! > > Laurent Laffont > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] HelpSystem (was ProfStef)
I like the idea. All what is help and documentation, I like it :) NowIt is not clear for me the differences between HelpSystem and ProfStef. Help system is new ? or it was in squeaksource several years ago ? which are the differences between them ? are they related ? should they be merged? when we should use one and when the other ? Of course that this will be cool to include in PharoDev (not in 1.0, thus) Thanks for any clarification. Mariano On Sat, Feb 13, 2010 at 1:46 PM, Danny Chan wrote: > Am Samstag, 13. Februar 2010 00:47:36 schrieb Torsten Bergmann: > > Page order is now defined using a method #pages. > > Also more help texts are added. Just try: > > > > - > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfHelpSystem'; > > load. > > > >(Smalltalk at: #ConfigurationOfHelpSystem) load. > > > > HelpSystem reset. > > HelpBrowser open > > > > - > > > > Have fun, > > T. > > > > > Hi! > > I like the browser with the icons and that you can nest books. I have > implemented some authoring capabilities in ProfStefBrowser to create new > tutorials, save changes to the current page or add another one, and to > reorder > pages on the fly. I also have a bit of code to jump to a particular > book/page > from code. I would like to add this to your code, maybe shown only in some > kind of expert mode controlled by a setting. I would like to have a help > system that can grow with the user's experience. Here are some additonal > ideas > I've had: > > - Seamless integration with Monticello, so that a user can rewrite parts of > a > tutorial and upload it directly from the browser to a tutorial inbox > - Integration of functionality from ScriptManager > - Some kind of simple markup language to have for example links to other > pages > or books, or to execute code snippets with a single mouse click > - I guess it is possible to highlight GUI elements somehow from code. > Wouldn't > it be cool to not have a lot of pictures in a help page that show your tool > and which button to click, but rather be able to highlight the right button > directly in the running tool? > - Following up on your idea about integration with tools, what about > integration with the debugger? Have a help item in every tool by default, > and > when you click on it have the option from the debugger to create a help > page > on the fly and submit it to the tool maintainer > > > What do you think? > > Cheers, Danny > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] HelpSystem (was ProfStef)
Am Samstag, 13. Februar 2010 00:47:36 schrieb Torsten Bergmann: > Page order is now defined using a method #pages. > Also more help texts are added. Just try: > > - > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfHelpSystem'; > load. > >(Smalltalk at: #ConfigurationOfHelpSystem) load. > > HelpSystem reset. > HelpBrowser open > > - > > Have fun, > T. > Hi! I like the browser with the icons and that you can nest books. I have implemented some authoring capabilities in ProfStefBrowser to create new tutorials, save changes to the current page or add another one, and to reorder pages on the fly. I also have a bit of code to jump to a particular book/page from code. I would like to add this to your code, maybe shown only in some kind of expert mode controlled by a setting. I would like to have a help system that can grow with the user's experience. Here are some additonal ideas I've had: - Seamless integration with Monticello, so that a user can rewrite parts of a tutorial and upload it directly from the browser to a tutorial inbox - Integration of functionality from ScriptManager - Some kind of simple markup language to have for example links to other pages or books, or to execute code snippets with a single mouse click - I guess it is possible to highlight GUI elements somehow from code. Wouldn't it be cool to not have a lot of pictures in a help page that show your tool and which button to click, but rather be able to highlight the right button directly in the running tool? - Following up on your idea about integration with tools, what about integration with the debugger? Have a help item in every tool by default, and when you click on it have the option from the debugger to create a help page on the fly and submit it to the tool maintainer What do you think? Cheers, Danny ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About String empty and others
Hi guys chris mueller proposed in squeak to have Exception>>messageText "Return an exception's message text." + ^ messageText ifNil: [ String empty ]! - - ^messageText! - Added Array class>>#empty and String class>>#empty to provide applications with canonicalized instances of these oft-used objects; since they are embedded as literals in the CompiledMethod. === Diff against Collections-ar.304 === Item was added: + - Method: Array class>>empty (in category 'instance creation') - + empty + "A canonicalized empty Array instance." + ^ #()! Item was added: + - Method: String class>>empty (in category 'instance creation') - + empty + "A canonicalized empty String instance." + ^ ''! Item was removed: - - Method: String>>asDefaultDecodedString (in category 'converting') - - asDefaultDecodedString - - ^ self http://code.google.com/p/pharo/issues/detail?id=1961 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11205
11205 - - FloatTest - UIManager>>request:initialAnswer:centerAt: and subclass. - RunArray class>>scanFrom: more robust - Issue 1961: Exception empty message and String empty - Issue 1955: Parser should parse 16rff Fixing digitValue: to be named digitValueOf: (part one) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about NumberParser
2010/2/13 Stéphane Ducasse : > Hi nicolas > > I like the idea to have an easy to customize parser number. > Do you have a slice that I could integrate once your changes are done. > Or show I go in squeak trunk and take the code? > I imagine that we could then package FORTRAN and ExtendedNumberParser in a > different package. > > http://code.google.com/p/pharo/issues/detail?id=1960 > Changes should be very easy to pick. FORTRANNumberParser is just a demonstrator and should find it's way out of kernel image. However, ExtendedNumberParser is designed for Kernel, for enhancing String>>asNumber. Nicolas > Stef > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fraction>>adaptToScaledDecimal:andSend:
2010/2/13 Stéphane Ducasse : > Hi nicolas > > I saw that you are working on squeak on Fraction and ScaledDecimal. > How is it related to the change we discussed a while ago about Float? > How squeak deals with the fact that scaledDecimal was not MIT (if I remember > correctly)? > I would like to avoid to diverge too quickly on numbers :) > > Stef Just putting Squeak to the level of Pharo :), I probably took the coercion test from Pharo,can't remember. Concerning license stuff, I'll wait announcement of 4.0, no hurry. But sure, there is no reason to diverge on core. Nicolas > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] web services, pharo
Hi, I would like to record a screencast with the following scenario: - search for pictures using Flickr web services, http://www.flickr.com/services/api/, XML-RPC response - parse the XML to get pictures URL - download pictures - display them in a morphic GUI Which packages should I use to use Web services, parse XML, download pictures ? Is there existing apps / code which do this sort of things ? Thanks ! Laurent Laffont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] about NumberParser
Hi nicolas I like the idea to have an easy to customize parser number. Do you have a slice that I could integrate once your changes are done. Or show I go in squeak trunk and take the code? I imagine that we could then package FORTRAN and ExtendedNumberParser in a different package. http://code.google.com/p/pharo/issues/detail?id=1960 Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo changing the game
2010/2/13 Stéphane Ducasse : > Send code and it will be fixed in one hour. > > Stef > And you'll break another feature 16r7Fe7. So you have to think twice... Nicolas >> I think the really tragic thing is that nothing in Smalltalk remains stable. >> >> It would seem to me that in a language that has been around thirty years or >> so that core data types like numbers, dates, times, and (hopefully, although >> adoption of unicode was disruptive) strings would be the same across all the >> dialects. >> >> By now, there should be some chunks of the system that we can deem fully >> mature and then learn to LEAVE ALONE. >> >> The 16rff issue is a fine example of an absolutely stupid incompatibility. >> >> Just my $.04 >> >> -Todd Blanchard >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fraction>>adaptToScaledDecimal:andSend:
Hi nicolas I saw that you are working on squeak on Fraction and ScaledDecimal. How is it related to the change we discussed a while ago about Float? How squeak deals with the fact that scaledDecimal was not MIT (if I remember correctly)? I would like to avoid to diverge too quickly on numbers :) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo changing the game
Send code and it will be fixed in one hour. Stef > I think the really tragic thing is that nothing in Smalltalk remains stable. > > It would seem to me that in a language that has been around thirty years or > so that core data types like numbers, dates, times, and (hopefully, although > adoption of unicode was disruptive) strings would be the same across all the > dialects. > > By now, there should be some chunks of the system that we can deem fully > mature and then learn to LEAVE ALONE. > > The 16rff issue is a fine example of an absolutely stupid incompatibility. > > Just my $.04 > > -Todd Blanchard > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DateAndTime and TimeStamp precision
Hi miguel
what is the solution?
I remember that I saw passing some code to support nanos
but I'm not sure that it was integrated.
Now let us fix it if possible.
Stef
On Feb 13, 2010, at 1:32 AM, Miguel Enrique Cobá Martinez wrote:
> El vie, 12-02-2010 a las 14:58 -0800, John M McIntosh escribió:
>> With the Mac VM 5.4b1 I have a microsecond clock.
>> http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html
>>
>> zero feedback, maybe it's too fast and you never get above 1 millisecond in
>> testing eh?
>
>
> Thanks that indeed shown a difference in my machine.
>
> But, then other question, why the default implementation of DateAndTime
> now and TimeStamp now isn't smaller than a second.
> By sending now I get a DateAndTime object but by sending
> millesecondClockValue a get a SmallInteger representing the number of
> milliseconds.
>
> But there isn't in the class side of both classes and neither in Time
> class a method to build a DateAndTime, a TimeStamp or a Time from
> milliseconds. So to convert this value to a date again I will have to
> trunk the time to a second resolution. Is this analysis correct?
>
> Of course I could index my objects in the list with the millis number
> but I would be happier if I could index them with a real date object.
>
> Anyway, not that that is a show stopper, is just that when creating
> objects I'm assigning a creation date and I would like to find what
> objects are older that others created at about the same lapse, without
> resorting to use their position in an external data structure (i.e. the
> OrderedCollection, an array or the line number in a file).
>
> Thanks to everyone for the answers.
>
>>
>>
>> On 2010-02-12, at 12:46 PM, csra...@bol.com.br wrote:
>>
>>> Miguel,
>>>
>>> Pharo allows you to drill down to millisecond resolution, but for your
>>> 'benchmark' that's still too coarse:
>>>
>>> {DateAndTime. TimeStamp } collect: [ :class |
>>> | list |
>>> list := OrderedCollection new.
>>> 1 to: 1000 do: [ :each |
>>> value := class millisecondClockValue.
>>> list add: value ].
>>> list last - list first ].
>>>
>>> I get an Array (1 1).
>>>
>>> Changing from 1000 to 10 (hundred fold) I got #(77 141).
>>>
>>> HTH
>>>
>>> --
>>> Cesar Rabak
>>>
>>> Em 12/02/2010 17:02, Miguel Enrique Cobá Martinez < miguel.c...@gmail.com >
>>> escreveu:
>>> I am noticing that both
>>>
>>> DateAndTime now
>>> TimeStamp now
>>>
>>> have a precision of seconds, that is, the nanos is always 0.
>>>
>>> I am doing a bulk data creation and inserting them in a list with a
>>> timestamp for each insertion but this isn't working because several
>>> entries have the very same DateAndTime or Timestamp.
>>>
>>> For example:
>>>
>>> {DateAndTime. TimeStamp } collect: [ :class |
>>> | list |
>>> list := OrderedCollection new.
>>> 1 to: 1000 do: [ :each |
>>> value := class now.
>>> list add: value ].
>>> list last - list first ]
>>>
>>> gives an Array(0:00:00:00 0:00:00:00)
>>>
>>> How can achieve smaller than a second timestamping in Pharo?
>>> --
>>> Miguel Cobá
>>> http://miguel.leugim.com.mx
>>>
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> --
>> ===
>> John M. McIntoshTwitter: squeaker68882
>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
>> ===
>>
>>
>>
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
