I do not understand where're lost. With Polymorph, with Smalltalk? Open a workspace, cut and paste one of the line below, select, right click and doIt. Alexandre On 19 Jun 2009, at 15:01, Juan Pablo Cook wrote:

Thanks a lot, but I'm a bit lost in pharo... Could you make a little example? Thanks a lot

On Fri, Jun 19, 2009 at 3:36 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Juan,

Try : UITheme exampleColorControls UITheme exampleBasicControls UITheme exampleGroups UITheme exampleOtherControls UITheme exampleWindowWithToolbars

The code to create these widget is there.

Alexandre

On 19 Jun 2009, at 14:32, Juan Pablo Cook wrote:

...

Hi Everybody! Today I found this smalltalk IDE, and I have recently installed. I used to use VisualWorks. I like the general interface of this framework. What I want to know is where I make a "new Canvas"? or a GUI Window? There is a palette with widgets and these things? Thanks a lot, I've been finding a free IDE to develop in Smalltalk.

Thanks a lot

JP Cook - Argentina _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________ 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

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Didn't I read somewhere that you can graphically "group" morphs together via a menu option (e.g. make one widget a child of another)? If so, and if relative positioning is preserved, then given how one can create morphs in a workspace, it seems like the capability is nearly there. We just need a browser to enable full binding to the callbacks/blocks and a code storage spec that is compact. It seems like it should be dead simple to build one from scratch, even if the capability I inquired about (in the first sentence of this email) is not present. I don't know what I am waiting for -- except more time -- because I guess I should build such a thing. (Are there any Pharo/squeak coders available for part-time consulting over the next year? ...At student level pay I must add.) I too want a GUI builder. -Cam On Jun 19, 2009, at 3:22 PM, Michael Roberts wrote:

I think the question was 'where is the UI builder'?. In VW you have a builder where you can drag and drop (to a certain extent) widgets on a canvas and define their properties. I'm not sure we have this in Pharo.

thanks,

I don't know what I am waiting for -- except more time -- because I guess I should build such a thing. (Are there any Pharo/squeak coders available for part-time consulting over the next year? ...At student level pay I must add.)

I too want a GUI builder.

me too :) So may be we could have a kind of bounty system for pharo. Frankly we are rather full and we (the core) have not that much time for extensions but we would support any work in the direction of UIBuilder TestServer Package.... FileWrite-Rio kind of integration Better MC support (yes I should look at MC1.5) Better SUnit Better tools (for example like the newInspector) Stef

Steve, Interesting that you mention value models. I just ran into a use for a ValueHolder, and discovered that Dolphin's #value, #value: protocol was not present. In fact ValueHolder>>value answers the receiver! I added an override to my Dolphin compatibility package. I exepect to add AspectValueAdapter and perhaps some converters as need arises. None of this takes away from Magritte; I share your interest in it and willingness to consider it as potentially powerful tool for GUI building. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Steve Wirts Sent: Friday, June 19, 2009 8:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making GUI'S Value Models, TypeConverter library, SubCanvas support(super powerful idea here), etc... some really wonderful idioms long lost in OO guis. VisualWorks had some really nice frameworks that were discarded due to them being undervalued. I hope to eventually re-introduce some of these fun frameworks into pharo given my time constraints and interest from potential users. see http://c2.com/ppr/vmodels.html Magritte seems like it might be a superior alternative to VisualWorks ValueModels; I haven't explored it enough to really know yet. Pharo is the most exciting thing to come along for me in quite awhile! On Fri, Jun 19, 2009 at 4:42 PM, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:

I don't know what I am waiting for -- except more time -- because I guess I should build such a thing. (Are there any Pharo/squeak coders available for part-time consulting over the next year? ...At student level pay I must add.)

I too want a GUI builder.

me too :) So may be we could have a kind of bounty system for pharo. Frankly we are rather full and we (the core) have not that much time for extensions but we would support any work in the direction of UIBuilder TestServer Package.... FileWrite-Rio kind of integration Better MC support (yes I should look at MC1.5) Better SUnit Better tools (for example like the newInspector) Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Just wondering if something similar can be done with Announcements? I think the Omnibrowser folks recently started wiring everything together using Announcments...? Not sure...just interested! Take care, Rob 2009/6/20 Steve Wirts <stevewirts@gmail.com>

I did a talk(attached) at OOPSLA several years ago to explain the benefits of ValueModels to java programmers, it was way over their heads. It's unfortunate as today I've yet to see anything in java that approaches the productivity they provide.

2009/6/20 Schwab,Wilhelm K <bschwab@anest.ufl.edu>

Steve,

...

Interesting that you mention value models. I just ran into a use for a ValueHolder, and discovered that Dolphin's #value, #value: protocol was not present. In fact ValueHolder>>value answers the receiver! I added an override to my Dolphin compatibility package. I exepect to add AspectValueAdapter and perhaps some converters as need arises.

None of this takes away from Magritte; I share your interest in it and willingness to consider it as potentially powerful tool for GUI building.

Bill

------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto: pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Steve Wirts *Sent:* Friday, June 19, 2009 8:01 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Making GUI'S

Value Models, TypeConverter library, SubCanvas support(super powerful idea here), etc... some really wonderful idioms long lost in OO guis. VisualWorks had some really nice frameworks that were discarded due to them being undervalued. I hope to eventually re-introduce some of these fun frameworks into pharo given my time constraints and interest from potential users.

see http://c2.com/ppr/vmodels.html

Magritte seems like it might be a superior alternative to VisualWorks ValueModels; I haven't explored it enough to really know yet. Pharo is the most exciting thing to come along for me in quite awhile!

On Fri, Jun 19, 2009 at 4:42 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

...

...

I don't know what I am waiting for -- except more time -- because I guess I should build such a thing. (Are there any Pharo/squeak coders available for part-time consulting over the next year? ...At student level pay I must add.)

I too want a GUI builder.

me too :) So may be we could have a kind of bounty system for pharo. Frankly we are rather full and we (the core) have not that much time for extensions but we would support any work in the direction of UIBuilder TestServer Package.... FileWrite-Rio kind of integration Better MC support (yes I should look at MC1.5) Better SUnit Better tools (for example like the newInspector)

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

Which I find funny because the one commercial grade swing app I did, I ended up building all that stuff because it was the only way I could see to get multiple views synced to the model without writing tons of glue code. Also, swing widgets don't like having null values as their data sources so the value models would keep them from throwing null pointer exceptions all the time. On Jun 20, 2009, at 4:25 AM, Steve Wirts wrote:

I did a talk(attached) at OOPSLA several years ago to explain the benefits of ValueModels to java programmers, it was way over their heads. It's unfortunate as today I've yet to see anything in java that approaches the productivity they provide.

2009/6/20 Schwab,Wilhelm K <bschwab@anest.ufl.edu> Steve,

Interesting that you mention value models. I just ran into a use for a ValueHolder, and discovered that Dolphin's #value, #value: protocol was not present. In fact ValueHolder>>value answers the receiver! I added an override to my Dolphin compatibility package. I exepect to add AspectValueAdapter and perhaps some converters as need arises.

None of this takes away from Magritte; I share your interest in it and willingness to consider it as potentially powerful tool for GUI building.

Bill

From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Steve Wirts Sent: Friday, June 19, 2009 8:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making GUI'S

Value Models, TypeConverter library, SubCanvas support(super powerful idea here), etc... some really wonderful idioms long lost in OO guis. VisualWorks had some really nice frameworks that were discarded due to them being undervalued. I hope to eventually re-introduce some of these fun frameworks into pharo given my time constraints and interest from potential users.

see http://c2.com/ppr/vmodels.html

Magritte seems like it might be a superior alternative to VisualWorks ValueModels; I haven't explored it enough to really know yet. Pharo is the most exciting thing to come along for me in quite awhile!

On Fri, Jun 19, 2009 at 4:42 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

...

wrote:

I don't know what I am waiting for -- except more time -- because I guess I should build such a thing. (Are there any Pharo/squeak coders available for part-time consulting over the next year? ...At student level pay I must add.)

I too want a GUI builder.

me too :) So may be we could have a kind of bounty system for pharo. Frankly we are rather full and we (the core) have not that much time for extensions but we would support any work in the direction of UIBuilder TestServer Package.... FileWrite-Rio kind of integration Better MC support (yes I should look at MC1.5) Better SUnit Better tools (for example like the newInspector)

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

<value models.ppt>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Have you looked at Smalltalk/X? Includes GUI builders, super fast and has ValueModels. Maybe Pharo can learn a bit from ST/X? See http://www.exept.de/en/products/smalltalk-x/stx-overview Regards Rudi On 20 Jun 2009, at 6:17 AM, Cameron Sanders <camsanders01@roadrunner.com> wrote:

To come back to Juan's latest question, let me say: I spent many months last year loading software development environments for a variety of programming languages to see the state of the world. And I found myself disappointed that we really haven't bested smalltalk yet. Smalltalk is great, I just figured... something better would have come along over the years. For ease of realizing a design vision, and platform independence, it is hard to beat smalltalk.

I could not commit to VisualWorks because of the licensing terms, for commercialize work. Dolphin is platform limited, and differs from the other smalltalks. VisualAge is too pricey! [I tried the other flavors too...] These are good tools, they just do not fit my requirements or means. After digging around, I like the licensing terms of Pharo. It is on the right track. It is rich in functionality. It works; it is robust.

I am strictly a user right now, but I will try to contribute in the future. I like Stef's idea of a "bounty" -- great idea!

So my advice for a free smalltalk is -- drumroll please... -- Pharo. But don't ignore Squeak itself, nor the variants, depending on your needs.

That said, the the lack of a GUI builder is a clear deficiency. But we will add one. [Ahem... i sound like royalty with my use of the word "we"; i co-authored one in C/X/motif in the 1980s... it should be at least that simple in smalltalk. The aforementioned tool took two of us about one week; but I know nothing about Morph at this time.] Depending on your needs, simple GUI's are easy to build with Morph, but sometimes (most?) i just want to paint the interface and give it some thought before fully wiring it. It allows one to quickly probe whether the vision(the GUI) is an acceptable/ comfortable/sufficient/... means for a user to interact with the application. Especially when working with others programmers, and worse, those pesky clients! Clients love interfaces.

(I still do not know what Polymorph is, is it a completely different system? a piggy-back system? They can co-exist right? but they use a different value-changed notification system?)

Pharo has value models, right? [Or am i... -- I'll look later.]

Again, thanks to the good work of the Pharo people (and Squeak people), I have found some sanity in life. I got tired of Python changing. I cannot stand strong typing. I love Smalltalk. And the best part is that it's free!

Cheers, Cam PS: speed is another high-priority. VisualWorks and Dolphin feel really snappy!

On Jun 19, 2009, at 9:01 PM, Steve Wirts wrote:

...

Value Models, TypeConverter library, SubCanvas support(super powerful idea here), etc... some really wonderful idioms long lost in OO guis. VisualWorks had some really nice frameworks that were discarded due to them being undervalued. I hope to eventually re-introduce some of these fun frameworks into pharo given my time constraints and interest from potential users.

see http://c2.com/ppr/vmodels.html

Magritte seems like it might be a superior alternative to VisualWorks ValueModels; I haven't explored it enough to really know yet. Pharo is the most exciting thing to come along for me in quite awhile!

On Fri, Jun 19, 2009 at 4:42 PM, Stéphane Ducasse <stephane.ducasse@inria.f r> wrote:

...

I don't know what I am waiting for -- except more time -- because I guess I should build such a thing. (Are there any Pharo/squeak

coders

...

available for part-time consulting over the next year? ...At student level pay I must add.)

I too want a GUI builder.

me too :) So may be we could have a kind of bounty system for pharo. Frankly we are rather full and we (the core) have not that much time for extensions but we would support any work in the direction of UIBuilder TestServer Package.... FileWrite-Rio kind of integration Better MC support (yes I should look at MC1.5) Better SUnit Better tools (for example like the newInspector)

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

On 20.06.2009, at 10:52, Cameron Sanders wrote:

They could probably all learn from the other flavors. In fact, the cross-smalltalk portability is a negative for smalltalk.

I believe I tried smalltalk/X... that's the natively-compiled one, right? So it feels like C++ if you change a root class -- or am I confusing it with another? I'm on a new platform and can't check what all I installed last year, at the moment.

I like the idea of a compiled version!! And there would be a place for it in my world, *if* I could take code from Pharo and load it into say, Smalltalk/X, and have it work without a month-long debugging session.

One huge problem with compatibility is always that it reduces any possibility in evolving/improving the system. If the goal is to be compatible to e.g. all of Smalltalk X, Visualworks, Squeak, Gemstone.... than, in the end, this means we can not do anything anymore, and, most importantly: we can not do any *fun* things anymore. Beeing compatible means reducing what you do to the subset of all the dialects, and than stop doing anything. If I you should choose between a) "inventing the future" and b) "be compatible to VisualWorks", what would you take? And I personally have already choosen for the "inventing the future" route, I guess. It makes no sense to be in Research (and beeing payed those wonderful tiny salaries) and than do boring stuff. That makes no sense. I personally think that the possibility and duty of working on interesting things is part of the overall compensation package of people in Research. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

On Jun 20, 2009, at 5:37 PM, Janko Mivšek wrote:

Hi Marcus,

I agree that compatibility reduce possibility to evolve/improve the system. But on the other hand being not compatible you risk to stay alone.

I think that everything lyes in clever judgment: how much to sty compatible and how much go into new, fresh and deeper waters.

yes we will see.

I'm sure it is good not to touch the Smalltalk core things like syntax and this is even not needed, Smalltalk fathers did a really good job to make its syntax eternally useful and feature complete.

exact. The Smalltalk syntax is nearly good. We have one for scripting in addition.

Libraries are something to evolve, but again very carefully the fundamental parts (collections,...) while other, like GUI, well, here are a lot of opportunities to evolve.

We will certainly touch the MOP (or its absence in Smalltalk). I want a safer Smalltalk I want security concept cool sandbox cool module may be new concurrency model new compilers well modularised system fast loading I would love to have cool visibility mechanism pluggable type systems

Best regards Janko

P.S.: Yes, that's how I evolve Aida/Web. Some parts are fixed, while other evolve like crazy. Without much compatibility hassles, so far.

May be at the end we will fork again and create something for researcher only but at least starting from a clean system. I see that as sound evolution. Stef

amd cpu, 768mb ram (physical), win xp sp3, pharo 0.1 #10342 debug>space left... 7,259,612 bytes (internal) 265,688,060 bytes (phusical) 515,704,284 bytes (total) Please send me to a page showing how to inerpret this... Quick question is: how much memory my actual pharo vm is connsuming and when the "low space watcher" is going to start sending alerts? Regards, Carlos

+ 100000000 :) I want to invent a reasonable future :) On Jun 20, 2009, at 5:22 PM, Marcus Denker wrote:

On 20.06.2009, at 10:52, Cameron Sanders wrote:

...

They could probably all learn from the other flavors. In fact, the cross-smalltalk portability is a negative for smalltalk.

I believe I tried smalltalk/X... that's the natively-compiled one, right? So it feels like C++ if you change a root class -- or am I confusing it with another? I'm on a new platform and can't check what all I installed last year, at the moment.

I like the idea of a compiled version!! And there would be a place for it in my world, *if* I could take code from Pharo and load it into say, Smalltalk/X, and have it work without a month-long debugging session.

One huge problem with compatibility is always that it reduces any possibility in evolving/improving the system. If the goal is to be compatible to e.g. all of Smalltalk X, Visualworks, Squeak, Gemstone.... than, in the end, this means we can not do anything anymore, and, most importantly: we can not do any *fun* things anymore.

Beeing compatible means reducing what you do to the subset of all the dialects, and than stop doing anything.

If I you should choose between a) "inventing the future" and b) "be compatible to VisualWorks", what would you take?

And I personally have already choosen for the "inventing the future" route, I guess. It makes no sense to be in Research (and beeing payed those wonderful tiny salaries) and than do boring stuff. That makes no sense.

I personally think that the possibility and duty of working on interesting things is part of the overall compensation package of people in Research.

Marcus

-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sat, 2009-06-20 at 21:46 +0200, Stéphane Ducasse wrote:

+ 100000000 :)

I want to invent a reasonable future :)

Your (Marcus and yours) mails sound a bit strange to me. Please let us not do this separation between academia and industria again. I don't think there is any option but to try to have both: stability and improvements. There should be a core that is as common as possible. And no, having a common core is not _the_ reason for not be able to change anything. For me that were the reasons to fork off from squeak. This dialect thing in smalltalk is really ridiculous. You cannot use such basic things like networking even across two different dialects. So you have to stay inside your own world/box. That is IMHO highly in- appropriate for these times. But I know some reasons why it is like this and that's the reason I can live with it. But there is room for improvement we should not miss. And I hope you can see that the support for basic technologies in smalltalk is way behind. The beauty and the strength of the language of smalltalk only lays within itself. Maybe I got you wrong but this mails triggered something in me so hence the more harsh tone :) Norbert On Jun 20, 2009, at 5:22 PM, Marcus Denker wrote:

...

On 20.06.2009, at 10:52, Cameron Sanders wrote:

...

They could probably all learn from the other flavors. In fact, the cross-smalltalk portability is a negative for smalltalk.

I believe I tried smalltalk/X... that's the natively-compiled one, right? So it feels like C++ if you change a root class -- or am I confusing it with another? I'm on a new platform and can't check what all I installed last year, at the moment.

I like the idea of a compiled version!! And there would be a place for it in my world, *if* I could take code from Pharo and load it into say, Smalltalk/X, and have it work without a month-long debugging session.

One huge problem with compatibility is always that it reduces any possibility in evolving/improving the system. If the goal is to be compatible to e.g. all of Smalltalk X, Visualworks, Squeak, Gemstone.... than, in the end, this means we can not do anything anymore, and, most importantly: we can not do any *fun* things anymore.

Beeing compatible means reducing what you do to the subset of all the dialects, and than stop doing anything.

If I you should choose between a) "inventing the future" and b) "be compatible to VisualWorks", what would you take?

And I personally have already choosen for the "inventing the future" route, I guess. It makes no sense to be in Research (and beeing payed those wonderful tiny salaries) and than do boring stuff. That makes no sense.

I personally think that the possibility and duty of working on interesting things is part of the overall compensation package of people in Research.

Marcus

-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

_______________________________________________ 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

My 2 cents: one of the ways to stay 'compatible' is become a de-facto standart because of high popularity :) 2009/6/21 Stéphane Ducasse <stephane.ducasse@inria.fr>:

On Jun 21, 2009, at 12:27 PM, Norbert Hartl wrote:

...

On Sat, 2009-06-20 at 21:46 +0200, Stéphane Ducasse wrote:

...

+ 100000000 :)

I want to invent a reasonable future :)

Your (Marcus and yours) mails sound a bit strange to me. Please let us not do this separation between academia and industria again. I don't think there is any option but to try to have both: stability and improvements. There should be a core that is as common as possible. And no, having a common core is not _the_ reason for not be able to change anything. For me that were the reasons to fork off from squeak.

Exact :)

...

This dialect thing in smalltalk is really ridiculous. You cannot use such basic things like networking even across two different dialects. So  you have to stay inside your own world/box. That is IMHO highly in- appropriate for these times. But I know some reasons why it is like this and that's the reason I can live with it. But there is room for improvement we should not miss.

totally true.

...

And I hope you can see that the support for basic technologies in smalltalk is way behind.

unfortunately

...

The beauty and the strength of the language of smalltalk only lays within itself.

Maybe I got you wrong but this mails triggered something in me so hence the more harsh tone :)

No problem, we are discussing :) Now we should not get trapped in the backward compatible compatibility with X and Z.

...

Norbert

On Jun 20, 2009, at 5:22 PM, Marcus Denker wrote:

...

...

On 20.06.2009, at 10:52, Cameron Sanders wrote:

...

They could probably all learn from the other flavors. In fact, the cross-smalltalk portability is a negative for smalltalk.

I believe I tried smalltalk/X... that's the natively-compiled one, right? So it feels like C++ if you change a root class -- or am I confusing it with another? I'm on a new platform and can't check what all I installed last year, at the moment.

I like the idea of a compiled version!! And there would be a place for it in my world, *if* I could take code from Pharo and load it into say, Smalltalk/X, and have it work without a month-long debugging session.

One huge problem with compatibility is always that it reduces any possibility in evolving/improving the system. If the goal is to be compatible to e.g. all of Smalltalk X, Visualworks, Squeak, Gemstone.... than, in the end, this means we can not do anything anymore, and, most importantly: we can not do any *fun* things anymore.

Beeing compatible means reducing what you do to the subset of all the dialects, and than stop doing anything.

If I you should choose between a) "inventing the future" and b) "be compatible to VisualWorks", what would you take?

And I personally have already choosen for the "inventing the future" route, I guess. It makes no sense to be in Research (and beeing payed those wonderful tiny salaries) and than do boring stuff. That makes no sense.

I personally think that the possibility and duty of working on interesting things is part of the overall compensation package of people in Research.

    Marcus

-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

_______________________________________________ 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 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.

One of my interests is building highly scalable (web-based) software applications. The advantage in using Smalltalk is that it has the nice possibility of being able to get (1) the wonderfully powerful development environment, (2) the incredible flexibility of the language and (3) *very* high performance deployment. In my opinion, Pharo is taking the right direction in the first two (getting proper closures finally into the Squak runtime is an example, as is the progress in refactoring and browsing, license cleaning, increased test coverage, etc.)... and adequate performance for many situations. For the very high performance need, Strongtalk looks like a very interesting platform to me, others may have their own preferences. For this to work there are two significant impediments: sharing code, and networking compatibility. Interestingly, Avi Bryant seems to have had his hand in addressing both (Monticello and Seaside compatibility modules). As Strongtalk seems to be a bit orphaned these days, I think a fruitful route would be to make the interfaces compatible with squeak/pharo, where possible. As for the overall question of compatibility, I think we should strive to have the lowest level infrastructure as compatible as possible, but lots of experimentation above that level. ../Dave

On 21.06.2009, at 06:27, Norbert Hartl wrote:

On Sat, 2009-06-20 at 21:46 +0200, Stéphane Ducasse wrote:

...

+ 100000000 :)

I want to invent a reasonable future :)

Your (Marcus and yours) mails sound a bit strange to me.

I guess my mail was not about Pharo, but more about me... Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Norbert, There were many reasons to fork from Squeak, and the improvements in Pharo would not have been possible any other way. I share your frustration at the lack of compatibility between dialects. Necessity being the mother of invention (and in this case the motiviation for same), I have started chipping away at the problem between Dolphin and Pharo. So far, it is little more than a collection of facades and helper methods that should reduce the hassles of getting my Dolphin code to run on Pharo. When that is all that is required, I think we should strive to make such layers available. Being different merely for its own sake buys us little. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Norbert Hartl Sent: Sunday, June 21, 2009 5:27 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making GUI'S On Sat, 2009-06-20 at 21:46 +0200, Stéphane Ducasse wrote:

+ 100000000 :)

I want to invent a reasonable future :)

Your (Marcus and yours) mails sound a bit strange to me. Please let us not do this separation between academia and industria again. I don't think there is any option but to try to have both: stability and improvements. There should be a core that is as common as possible. And no, having a common core is not _the_ reason for not be able to change anything. For me that were the reasons to fork off from squeak. This dialect thing in smalltalk is really ridiculous. You cannot use such basic things like networking even across two different dialects. So you have to stay inside your own world/box. That is IMHO highly in- appropriate for these times. But I know some reasons why it is like this and that's the reason I can live with it. But there is room for improvement we should not miss. And I hope you can see that the support for basic technologies in smalltalk is way behind. The beauty and the strength of the language of smalltalk only lays within itself. Maybe I got you wrong but this mails triggered something in me so hence the more harsh tone :) Norbert On Jun 20, 2009, at 5:22 PM, Marcus Denker wrote:

...

On 20.06.2009, at 10:52, Cameron Sanders wrote:

...

They could probably all learn from the other flavors. In fact, the cross-smalltalk portability is a negative for smalltalk.

I believe I tried smalltalk/X... that's the natively-compiled one, right? So it feels like C++ if you change a root class -- or am I confusing it with another? I'm on a new platform and can't check what all I installed last year, at the moment.

I like the idea of a compiled version!! And there would be a place for it in my world, *if* I could take code from Pharo and load it into say, Smalltalk/X, and have it work without a month-long debugging session.

One huge problem with compatibility is always that it reduces any possibility in evolving/improving the system. If the goal is to be compatible to e.g. all of Smalltalk X, Visualworks, Squeak, Gemstone.... than, in the end, this means we can not do anything anymore, and, most importantly: we can not do any *fun* things anymore.

Beeing compatible means reducing what you do to the subset of all the dialects, and than stop doing anything.

If I you should choose between a) "inventing the future" and b) "be compatible to VisualWorks", what would you take?

And I personally have already choosen for the "inventing the future" route, I guess. It makes no sense to be in Research (and beeing payed those wonderful tiny salaries) and than do boring stuff. That makes no sense.

I personally think that the possibility and duty of working on interesting things is part of the overall compensation package of people in Research.

Marcus

-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

_______________________________________________ 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

On Jun 22, 2009, at 9:09 AM, Norbert Hartl wrote:

Hi Bill,

no need to argue here. I'm on the same track. I think pharo is doing it really well. I welcome all of these changes, too. My biggest problem with pharo is that I don't have enough time to participate more.

I just thought I heard something like "Absolutely now reason to look back..." and to this I can't agree.

Me too. We look back. I'm sad to see the state of image segment and a lot of cool infrastructure. I think that the infrastructure is key to help improving (for example the notification system introduced by roel...) having a more agile system should help idea and project to come to live and create a rich biotop. For example a real mop could be good for persistency, magritte like meta model.....

But I think I was a bit to sensible in hearing anything bad :) And of course I don't want to sound like any of these old complaints that made this project come to live. So this shall be my excuse if it was taken as such.

Don't worry. I think that on a regular basis we will raise the point to make sure people got the idea that we want the better for the better :) :)

Norbert

On Sun, 2009-06-21 at 18:21 -0400, Schwab,Wilhelm K wrote:

...

Norbert,

There were many reasons to fork from Squeak, and the improvements in Pharo would not have been possible any other way. I share your frustration at the lack of compatibility between dialects. Necessity being the mother of invention (and in this case the motiviation for same), I have started chipping away at the problem between Dolphin and Pharo. So far, it is little more than a collection of facades and helper methods that should reduce the hassles of getting my Dolphin code to run on Pharo. When that is all that is required, I think we should strive to make such layers available. Being different merely for its own sake buys us little.

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Norbert Hartl Sent: Sunday, June 21, 2009 5:27 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making GUI'S

On Sat, 2009-06-20 at 21:46 +0200, Stéphane Ducasse wrote:

...

+ 100000000 :)

I want to invent a reasonable future :)

Your (Marcus and yours) mails sound a bit strange to me. Please let us not do this separation between academia and industria again. I don't think there is any option but to try to have both: stability and improvements. There should be a core that is as common as possible. And no, having a common core is not _the_ reason for not be able to change anything. For me that were the reasons to fork off from squeak.

This dialect thing in smalltalk is really ridiculous. You cannot use such basic things like networking even across two different dialects. So you have to stay inside your own world/box. That is IMHO highly in- appropriate for these times. But I know some reasons why it is like this and that's the reason I can live with it. But there is room for improvement we should not miss. And I hope you can see that the support for basic technologies in smalltalk is way behind. The beauty and the strength of the language of smalltalk only lays within itself.

Maybe I got you wrong but this mails triggered something in me so hence the more harsh tone :)

Norbert

On Jun 20, 2009, at 5:22 PM, Marcus Denker wrote:

...

...

On 20.06.2009, at 10:52, Cameron Sanders wrote:

...

They could probably all learn from the other flavors. In fact, the cross-smalltalk portability is a negative for smalltalk.

I believe I tried smalltalk/X... that's the natively-compiled one, right? So it feels like C++ if you change a root class -- or am I confusing it with another? I'm on a new platform and can't check what all I installed last year, at the moment.

I like the idea of a compiled version!! And there would be a place for it in my world, *if* I could take code from Pharo and load it into say, Smalltalk/X, and have it work without a month-long debugging session.

One huge problem with compatibility is always that it reduces any possibility in evolving/improving the system. If the goal is to be compatible to e.g. all of Smalltalk X, Visualworks, Squeak, Gemstone.... than, in the end, this means we can not do anything anymore, and, most importantly: we can not do any *fun* things anymore.

Beeing compatible means reducing what you do to the subset of all the dialects, and than stop doing anything.

If I you should choose between a) "inventing the future" and b) "be compatible to VisualWorks", what would you take?

And I personally have already choosen for the "inventing the future" route, I guess. It makes no sense to be in Research (and beeing payed those wonderful tiny salaries) and than do boring stuff. That makes no sense.

I personally think that the possibility and duty of working on interesting things is part of the overall compensation package of people in Research.

Marcus

-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

_______________________________________________ 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 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

As i remember there are somithing called EasyMorphic. Maybe it could adapted to Polymorph? On Sun, Jun 21, 2009 at 06:04, Serge Stinckwich<serge.stinckwich@gmail.com> wrote:

On Sat, Jun 20, 2009 at 10:22 PM, Marcus Denker<denker@acm.org> wrote:

...

...

And I personally have already choosen for the "inventing the future" route, I guess. It makes no sense to be in Research (and beeing payed those wonderful tiny salaries) and than do boring stuff. That makes no sense.

I personally think that the possibility and duty of working on interesting things is part of the overall compensation package of people in Research.

I like your argument ;-)

-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

our goal is to make sure that you will have a nice clean system to build such cool libraries. Stef On Jun 20, 2009, at 3:01 AM, Steve Wirts wrote:

Value Models, TypeConverter library, SubCanvas support(super powerful idea here), etc... some really wonderful idioms long lost in OO guis. VisualWorks had some really nice frameworks that were discarded due to them being undervalued. I hope to eventually re-introduce some of these fun frameworks into pharo given my time constraints and interest from potential users.

see http://c2.com/ppr/vmodels.html

Magritte seems like it might be a superior alternative to VisualWorks ValueModels; I haven't explored it enough to really know yet. Pharo is the most exciting thing to come along for me in quite awhile!

On Fri, Jun 19, 2009 at 4:42 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

...

wrote:

I don't know what I am waiting for -- except more time -- because I guess I should build such a thing. (Are there any Pharo/squeak coders available for part-time consulting over the next year? ...At student level pay I must add.)

I too want a GUI builder.

me too :) So may be we could have a kind of bounty system for pharo. Frankly we are rather full and we (the core) have not that much time for extensions but we would support any work in the direction of UIBuilder TestServer Package.... FileWrite-Rio kind of integration Better MC support (yes I should look at MC1.5) Better SUnit Better tools (for example like the newInspector)

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

Ah ok, And a question, If you can help me... What framework with a UiBuilder for Smalltalk free there is? It's a problem I think... Thanks a lot JP Cook On Fri, Jun 19, 2009 at 5:09 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

wrote:

HI juan

there is no UiBUilder as in VW in pharo. This is not that we do not like but nobody implemented it yet :)

Stef

On Jun 19, 2009, at 8:32 PM, Juan Pablo Cook wrote:

...

Hi Everybody! Today I found this smalltalk IDE, and I have recently installed. I used to use VisualWorks. I like the general interface of this framework. What I want to know is where I make a "new Canvas"? or a GUI Window? There is a palette with widgets and these things? Thanks a lot, I've been finding a free IDE to develop in Smalltalk.

Thanks a lot

JP Cook - Argentina _______________________________________________ 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