Switching to Pharo from Visualworks
Hello PharoDev, I have a largish project (Siren) that I have developed in ST80/VisualWorks (since 1984) and ported to Squeak in the past. I'm allows looking for a cleaner free ST80 implementation to host the project. Looking at Pharo, it appears to me to be suffering the same bloat issues as Squeak. I have a few questions: Why don't you all use a 6-paned browser (called the package browser in Squeak) and control the introduction of top-level meta-categories? The top-level (packages or meta-catgories) should be a list of 20 or fewer topics such as Magnitudes, Collections, Graphics, Text, Compiler, Tools, etc. and each of these should have 20 or fewer categories within it. I ported the package browser to Squeak and reorganized their system once, but people continued to add top-level categories to make finding their code easier. I tried to add the facility to the Pharo browser a year or so ago, and gave up because I couldn't figure how out how to subclass and refine the existing browser framework (and the fact that it seems to be under construction). Why do you still use the (terrible, IMHO) Squeak graphics and UI packages (Morphic, Balloon, etc)? It appears that new mostly-redundant systems are still being added to replace these, right? Can't someone reimplement the VisualWorks "Wrapper" UI framework (or something like it) on top of OpenGL contexts as in VW? It's help up pretty well after over 25 years. (David Leibs and I toasted it just last December in Australia.) How does a newbie learn what all the new packages are for? Glamour, Ring, AsmJit, Zinc, etc. are neat names, but if they're not part of higher-level packages it makes navigating the system (and even figuring out what they're for) pretty difficult. Are there any benchmarks of the current VMs compared to VisualWorks? The last time I used Squeak (a few years ago) it was still pretty slow. I have a real-time event scheduler in Siren that I use to schedule MIDI, so I can run "drum roll" tests to see how the VM performs. How does Pharo handle user primitives or foreign function calls? Is anyone maintaining the old SWIG implementation of Smalltalk? I used it quite a bit to have Smalltalk code create and manage C++ signal processing graphs in the past. SWIG is still going strong, and it's embarrassing that there's no mention at all of Smalltalk on the SWIG pages. I'm not trying to start a fight, and I really did like the initial Pharo mission statement of making a tighter, cleaner open-source ST80 implementation. Is that dream still what motivates the community? If yes, where are the minimalists hiding? Stephen Pope HeavenEverywhere Media and FASTLabInc.com Santa Barbara, CA USA -- Stephen Travis Pope Santa Barbara, California, USA http://HeavenEverywhere.com <http://heaveneverywhere.com/>
Le 5 févr. 2015 02:30, "Stephen Travis Pope" <stephen@heaveneverywhere.com> a écrit :
Hello PharoDev,
I have a largish project (Siren) that I have developed in ST80/VisualWorks (since 1984) and ported to Squeak in the past.
I'm allows looking for a cleaner free ST80 implementation to host the project.
Looking at Pharo, it appears to me to be suffering the same bloat issues
as
Squeak.
I have a few questions:
Why don't you all use a 6-paned browser (called the package browser in Squeak) and control the introduction of top-level meta-categories? The top-level (packages or meta-catgories) should be a list of 20 or fewer topics such as Magnitudes, Collections, Graphics, Text, Compiler, Tools, etc. and each of these should have 20 or fewer categories within it. I ported the package browser to Squeak and reorganized their system once, but people continued to add top-level categories to make finding their code easier. I tried to add the facility to the Pharo browser a year or so ago, and gave up because I couldn't figure how out how to subclass and refine the existing browser framework (and the fact that it seems to be under construction).
Why do you still use the (terrible, IMHO) Squeak graphics and UI packages (Morphic, Balloon, etc)? It appears that new mostly-redundant systems are still being added to replace these, right? Can't someone reimplement the VisualWorks "Wrapper" UI framework (or something like it) on top of OpenGL contexts as in VW? It's help up pretty well after over 25 years. (David Leibs and I toasted it just last December in Australia.)
How does a newbie learn what all the new packages are for? Glamour, Ring, AsmJit, Zinc, etc. are neat names, but if they're not part of higher-level packages it makes navigating the system (and even figuring out what they're for) pretty difficult.
Are there any benchmarks of the current VMs compared to VisualWorks? The last time I used Squeak (a few years ago) it was still pretty slow. I have a real-time event scheduler in Siren that I use to schedule MIDI, so I can run "drum roll" tests to see how the VM performs.
How does Pharo handle user primitives or foreign function calls? Is anyone maintaining the old SWIG implementation of Smalltalk? I used it quite a bit to have Smalltalk code create and manage C++ signal processing graphs in the past. SWIG is still going strong, and it's embarrassing that there's no mention at all of Smalltalk on the SWIG pages.
I'm not trying to start a fight, and I really did like the initial Pharo mission statement of making a tighter, cleaner open-source ST80 implementation. Is that dream still what motivates the community? If yes, where are the minimalists hiding?
There aren't that many high level categories. Any trip to Java? One can reduce the list with any regex in the box above the list and get that reduced list. e.g. ^Kernel There is a SWIG that supports Pharo. Check the Woden project as it used SWIG to wrap OpenGL/OpenCL. The SWIG thing is in the rmGithub repo of the Woden developer. Read Deep into Pharo for explanations on some packages. Also go to squarebaracketsassociates on github for books in progress etc. Id you want to create browsers maybe your best bet is to go the GToolkit route. Glamour is the framework supporting all of that. Nautilus can feel a bit unfinished but that's one get when challenging the status quo and learning how to go the the next level. Graphics are supported by Athens which wraps Cairo. Look in there, there is quite useful material. OSWindow and libSDL bindings open the door to better/faster interactions. I like Morphic and Balloon as they help me get how things are happening under the hood. FFI options experiences lots of attention at the moment. FFI as in original FFI works. Alien is there but kind of stale. NativeBoost works on x86 uFFI is a bew thing. One can also use the CCodeGenerator from inside the image. Need to load it first. BTW, I like your work and would love to see it working in Pharo. HTH Phil
Stephen Pope HeavenEverywhere Media and FASTLabInc.com Santa Barbara, CA USA
--
Stephen Travis Pope Santa Barbara, California, USA
On Thu, Feb 5, 2015 at 2:30 AM, Stephen Travis Pope < stephen@heaveneverywhere.com> wrote:
Hello PharoDev,
Hi Stephen,
I have a largish project (Siren) that I have developed in ST80/VisualWorks (since 1984) and ported to Squeak in the past.
I'm allows looking for a cleaner free ST80 implementation to host the project.
I would love if Siren is ported to Pharo ;-)
Looking at Pharo, it appears to me to be suffering the same bloat issues as Squeak.
I have a few questions:
Why don't you all use a 6-paned browser (called the package browser in Squeak) and control the introduction of top-level meta-categories? The top-level (packages or meta-catgories) should be a list of 20 or fewer topics such as Magnitudes, Collections, Graphics, Text, Compiler, Tools, etc. and each of these should have 20 or fewer categories within it. I ported the package browser to Squeak and reorganized their system once, but people continued to add top-level categories to make finding their code easier. I tried to add the facility to the Pharo browser a year or so ago, and gave up because I couldn't figure how out how to subclass and refine the existing browser framework (and the fact that it seems to be under construction).
There is no such tools in Pharo, but you can use the filter to see only the package you want. You may have a look to the AltBrowser of Thierry Goubier : http://thierrygoubier.github.io/AltBrowser/ There is a hierarchical view like the one you want. Normally you can load directement AltBrowser from Pharo 3.0/4.0: launch the configuration browser and select AltBrowser.
Why do you still use the (terrible, IMHO) Squeak graphics and UI packages (Morphic, Balloon, etc)? It appears that new mostly-redundant systems are still being added to replace these, right? Can't someone reimplement the VisualWorks "Wrapper" UI framework (or something like it) on top of OpenGL contexts as in VW? It's help up pretty well after over 25 years. (David Leibs and I toasted it just last December in Australia.)
If you want to build interface, you don't have to use Morphic, etc ... You can use Spec : http://spec.st/
How does a newbie learn what all the new packages are for? Glamour, Ring, AsmJit, Zinc, etc. are neat names, but if they're not part of higher-level packages it makes navigating the system (and even figuring out what they're for) pretty difficult.
Glamour is part of MOOSE image : http://www.moosetechnology.org/ This is a DSL to build browser You may have a look to the ongoing books. There is some documentation about all these framework: https://ci.inria.fr/pharo-contribution/view/Books/
Are there any benchmarks of the current VMs compared to VisualWorks? The last time I used Squeak (a few years ago) it was still pretty slow. I have a real-time event scheduler in Siren that I use to schedule MIDI, so I can run "drum roll" tests to see how the VM performs.
Pharo and Squeak use basically the same VM.
When you use Squeak, this was the stack VM or the newer one called Cog ? There will be a new VM called Spur with even more performances during the year.
How does Pharo handle user primitives or foreign function calls? Is anyone maintaining the old SWIG implementation of Smalltalk? I used it quite a bit to have Smalltalk code create and manage C++ signal processing graphs in the past. SWIG is still going strong, and it's embarrassing that there's no mention at all of Smalltalk on the SWIG pages.
There is many FFI engines at the moment. This problem was discussed during last PharoDays and there will be an action to have one unified FFI.
I'm not trying to start a fight, and I really did like the initial Pharo mission statement of making a tighter, cleaner open-source ST80 implementation. Is that dream still what motivates the community? If yes, where are the minimalists hiding?
There are still there, but it takes a lot of time to clean the implementation. One new statement of Pharo is to reinvent the UI also. There are some ongoing experiments with the GT-Tools: http://gt.moosetechnology.org/ Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Wed, 4 Feb 2015 19:30:38 -0600 Stephen Travis Pope <stephen@heaveneverywhere.com> wrote:
How does a newbie learn what all the new packages are for? Glamour, Ring, AsmJit, Zinc, etc. are neat names, but if they're not part of higher-level packages it makes navigating the system (and even figuring out what they're for) pretty difficult.
+1 to that one. -- Markus Fritsche <mfritsche@reauktion.de>
- Glamour : https://ci.inria.fr/pharo-contribution/view/Books/job/DeepIntoPharo/lastSucc... - Zinc : https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Zinc-... On Thu, Feb 5, 2015 at 11:37 AM, Markus Fritsche <mfritsche@reauktion.de> wrote:
On Wed, 4 Feb 2015 19:30:38 -0600 Stephen Travis Pope <stephen@heaveneverywhere.com> wrote:
How does a newbie learn what all the new packages are for? Glamour, Ring, AsmJit, Zinc, etc. are neat names, but if they're not part of higher-level packages it makes navigating the system (and even figuring out what they're for) pretty difficult.
+1 to that one.
-- Markus Fritsche <mfritsche@reauktion.de>
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Thu, 5 Feb 2015 11:45:53 +0100 Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
- Glamour : https://ci.inria.fr/pharo-contribution/view/Books/job/DeepIntoPharo/lastSucc... - Zinc : https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Zinc-...
Thanks, but that was meant more general. If I fire up the Pharo Launcher and go to the configuration browser, I see 25 offerings on the first page, of which roughly 50% (12) give me an idea what they're about. The other 13 - I really have no clue and need to google them ;-) If I'm having a problem with the browser implementation, AltBrowser might be a thing to look at. If "SuperGemMiley" (which might also implement an alternative browser) is something I should look at, I will only find out if I google "<name> pharo" and write down whatever comes up on github, smalltalkhub, jenkins... :-) Best regards, Markus -- Markus Fritsche <mfritsche@reauktion.de>
On Thu, Feb 5, 2015 at 11:57 AM, Markus Fritsche <mfritsche@reauktion.de> wrote:
On Thu, 5 Feb 2015 11:45:53 +0100 Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
- Glamour : https://ci.inria.fr/pharo-contribution/view/Books/job/DeepIntoPharo/lastSucc... - Zinc : https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Zinc-...
Thanks, but that was meant more general.
If I fire up the Pharo Launcher and go to the configuration browser, I see 25 offerings on the first page, of which roughly 50% (12) give me an idea what they're about. The other 13 - I really have no clue and need to google them ;-)
Yes, yes are right. At the moment, there is no catalog to understand what are the libraries/packages you could load into a Pharo image. There is an ongoing work to have a catalog here: https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/ but at the moment not all informations are available.
If I'm having a problem with the browser implementation, AltBrowser might be a thing to look at. If "SuperGemMiley" (which might also implement an alternative browser) is something I should look at, I will only find out if I google "<name> pharo" and write down whatever comes up on github, smalltalkhub, jenkins... :-)
Having a catalog will definitively help here. You should talk to Stéphane if you want to help us on this. Thank you. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Thu, 5 Feb 2015 12:03:11 +0100 Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
Having a catalog will definitively help here. You should talk to Stéphane if you want to help us on this.
Something I already thought of a year ago or so. To put something on a scratchpad: Tricky bit is to make it sustainable, packages are scattered because the community doesn't want to impose a way of working (which is legit). I would think a wiki-like catalogue, where authors can describe their solution/ code should be considered. That way, if someone doesn't care to describe, someone else could do it for him. The only link should be the name - no other meta data like versions and so on, since a package in the configuration browser should be pretty self contained. Hosting must be closely tied to the Pharo infrastructure. I know from experience, if I was to setup something on my iron, I'd lose interest with a few quarters and it would develop into another "tried it, didn't work, can't shutoff, can't migrate away" sort of thing... Best regards, Markus -- Markus Fritsche <mfritsche@reauktion.de>
Le 5/2/15 11:57, Markus Fritsche a écrit :
On Thu, 5 Feb 2015 11:45:53 +0100 Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
- Glamour : https://ci.inria.fr/pharo-contribution/view/Books/job/DeepIntoPharo/lastSucc... - Zinc : https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Zinc-... Thanks, but that was meant more general.
If I fire up the Pharo Launcher and go to the configuration browser, I see 25 offerings on the first page, of which roughly 50% (12) give me an idea what they're about. The other 13 - I really have no clue and need to google them ;-)
if the project configurationOf defines a description the flybyhelp shows its description when you load it. Now this is only until recently that ConfigurationOf were kept in the image so we will revisit the description to make sure that they are defined.
If I'm having a problem with the browser implementation, AltBrowser might be a thing to look at. If "SuperGemMiley" (which might also implement an alternative browser) is something I should look at, I will only find out if I google "<name> pharo" and write down whatever comes up on github, smalltalkhub, jenkins... :-)
We are **working** on a package catalog web site.
Best regards, Markus
Markus Fritsche-4 wrote
+1 to that one.
Yes, I also find it difficult - much more so when I was new to the community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be catchy, but when I'm browsing the system, I just want to see where the darn WebClient is, not mine for minerals or go to the beach!! ;) j/k. But seriously, it's one thing to have "sexy" names at the top level - Pharo, Squeak, Ruby, Python; but inside the system, it definitely creates confusion. It's perhaps extra difficult for us because some of these projects have both an outside and inside identity. It's an interesting open problem... maybe some metadata at the MetaC/package level could help? Like some standard tags like #WebClient, #Compiler, etc to say logically what role a project fills... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Java has hadoop, spark, swing, spring, jaxb, jta, jdbc, atomikos, quartz, velocity, beanshell, ... iOS has a ton of weird names as well in frameworks. Knowing the lay of the land is part of taking part of any ecosystem. I actually like the names. As of VW you tell me what AppeX and SiouX are without knowing upfront. Phil Le 6 févr. 2015 12:48, "Sean P. DeNigris" <sean@clipperadams.com> a écrit :
Markus Fritsche-4 wrote
+1 to that one.
Yes, I also find it difficult - much more so when I was new to the community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be catchy, but when I'm browsing the system, I just want to see where the darn WebClient is, not mine for minerals or go to the beach!! ;) j/k. But seriously, it's one thing to have "sexy" names at the top level - Pharo, Squeak, Ruby, Python; but inside the system, it definitely creates confusion. It's perhaps extra difficult for us because some of these projects have both an outside and inside identity. It's an interesting open problem... maybe some metadata at the MetaC/package level could help? Like some standard tags like #WebClient, #Compiler, etc to say logically what role a project fills...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yes, we need to improve that. Names are nice, but they make it harder to explore the system.
On 06 Feb 2015, at 12:43, Sean P. DeNigris <sean@clipperadams.com> wrote:
Markus Fritsche-4 wrote
+1 to that one.
Yes, I also find it difficult - much more so when I was new to the community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be catchy, but when I'm browsing the system, I just want to see where the darn WebClient is, not mine for minerals or go to the beach!! ;) j/k. But seriously, it's one thing to have "sexy" names at the top level - Pharo, Squeak, Ruby, Python; but inside the system, it definitely creates confusion. It's perhaps extra difficult for us because some of these projects have both an outside and inside identity. It's an interesting open problem... maybe some metadata at the MetaC/package level could help? Like some standard tags like #WebClient, #Compiler, etc to say logically what role a project fills...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
there should be both: a name and a category Seaside - Web framework Zinc - HTTP server etc. Esteban
On 06 Feb 2015, at 16:16, Marcus Denker <marcus.denker@inria.fr> wrote:
Yes, we need to improve that. Names are nice, but they make it harder to explore the system.
On 06 Feb 2015, at 12:43, Sean P. DeNigris <sean@clipperadams.com> wrote:
Markus Fritsche-4 wrote
+1 to that one.
Yes, I also find it difficult - much more so when I was new to the community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be catchy, but when I'm browsing the system, I just want to see where the darn WebClient is, not mine for minerals or go to the beach!! ;) j/k. But seriously, it's one thing to have "sexy" names at the top level - Pharo, Squeak, Ruby, Python; but inside the system, it definitely creates confusion. It's perhaps extra difficult for us because some of these projects have both an outside and inside identity. It's an interesting open problem... maybe some metadata at the MetaC/package level could help? Like some standard tags like #WebClient, #Compiler, etc to say logically what role a project fills...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yes, but that is not really provided as a #catalog* method, is it ? There is #catalogDescription, but that is some lines of text. There should be something like #catalogLabel for a sjort one-line title style label.
On 06 Feb 2015, at 16:26, Esteban Lorenzano <estebanlm@gmail.com> wrote:
there should be both: a name and a category
Seaside - Web framework Zinc - HTTP server etc.
Esteban
On 06 Feb 2015, at 16:16, Marcus Denker <marcus.denker@inria.fr> wrote:
Yes, we need to improve that. Names are nice, but they make it harder to explore the system.
On 06 Feb 2015, at 12:43, Sean P. DeNigris <sean@clipperadams.com> wrote:
Markus Fritsche-4 wrote
+1 to that one.
Yes, I also find it difficult - much more so when I was new to the community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be catchy, but when I'm browsing the system, I just want to see where the darn WebClient is, not mine for minerals or go to the beach!! ;) j/k. But seriously, it's one thing to have "sexy" names at the top level - Pharo, Squeak, Ruby, Python; but inside the system, it definitely creates confusion. It's perhaps extra difficult for us because some of these projects have both an outside and inside identity. It's an interesting open problem... maybe some metadata at the MetaC/package level could help? Like some standard tags like #WebClient, #Compiler, etc to say logically what role a project fills...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 6/2/15 16:31, Sven Van Caekenberghe a écrit :
Yes, but that is not really provided as a #catalog* method, is it ?
There is #catalogDescription, but that is some lines of text.
There should be something like #catalogLabel for a sjort one-line title style label.
if configuration would be filled up we could take advantage of them. The flybyhelp when hovering over a package is displaying the description of project (when there is one) since two years. Stef
On 06 Feb 2015, at 16:26, Esteban Lorenzano <estebanlm@gmail.com> wrote:
there should be both: a name and a category
Seaside - Web framework Zinc - HTTP server etc.
Esteban
On 06 Feb 2015, at 16:16, Marcus Denker <marcus.denker@inria.fr> wrote:
Yes, we need to improve that. Names are nice, but they make it harder to explore the system.
On 06 Feb 2015, at 12:43, Sean P. DeNigris <sean@clipperadams.com> wrote:
Markus Fritsche-4 wrote
+1 to that one. Yes, I also find it difficult - much more so when I was new to the community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be catchy, but when I'm browsing the system, I just want to see where the darn WebClient is, not mine for minerals or go to the beach!! ;) j/k. But seriously, it's one thing to have "sexy" names at the top level - Pharo, Squeak, Ruby, Python; but inside the system, it definitely creates confusion. It's perhaps extra difficult for us because some of these projects have both an outside and inside identity. It's an interesting open problem... maybe some metadata at the MetaC/package level could help? Like some standard tags like #WebClient, #Compiler, etc to say logically what role a project fills...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Am 06.02.15 12:43, schrieb Sean P. DeNigris:
Markus Fritsche-4 wrote
+1 to that one. Yes, I also find it difficult - much more so when I was new to the community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be catchy, but when I'm browsing the system, I just want to see where the darn WebClient is, not mine for minerals or go to the beach!! ;) j/k. But +1 The names of these frameworks are nice as long as they are outside the image. Inside the image the focus should be on functionality (at least as long as the frameworks are unique).
For somebody new to Pharo this is quite irritating. Andreas
seriously, it's one thing to have "sexy" names at the top level - Pharo, Squeak, Ruby, Python; but inside the system, it definitely creates confusion. It's perhaps extra difficult for us because some of these projects have both an outside and inside identity. It's an interesting open problem... maybe some metadata at the MetaC/package level could help? Like some standard tags like #WebClient, #Compiler, etc to say logically what role a project fills...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi steven
I have a largish project (Siren) that I have developed in ST80/VisualWorks (since 1984) and ported to Squeak in the past.
I'm allows looking for a cleaner free ST80 implementation to host the project.
Good. I would love to see Siren in Pharo and I'm ready to help.
Looking at Pharo, it appears to me to be suffering the same bloat issues as Squeak.
Well if you say that it is that you are just looking at the tip of iceberg. This is not for fun that we are massively working on cleaning dependencies and removing wrong code or rewriting it. In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now. Bootstrapping means a lot in term of quality. But we have some work to get there and we are busy with our real work (publishing papers). BTW: When I come to friend place I do not start to piss on the door, usually I try to understand the tradition of the place and get more information before judging. I will take your remarks with a bit of salt and reply to you as a welcome message. :)
I have a few questions:
Why don't you all use a 6-paned browser (called the package browser in Squeak) and control the introduction of top-level meta-categories? Because you have tags and you can filter packages. Now the new browser is not the final answer. You could imagine also that your browser is empty at first and only contain your projects and that you can add incrementally the class and packages of interest. Now we did not have the cycle to experiment with that and hope other people will try. We should do another pass on cleaning simplifying nautilus.
Thetop-level (packages or meta-catgories) should be a list of 20 or fewer topics such as Magnitudes, Collections, Graphics, Text, Compiler, Tools, etc. and each of these should have 20 or fewer categories within it It is just a view on the world. Why would I be interested in Magnitudes. I have no idea what it is and I do not care. But we are working on it. We should restart. First we needed to throw away the old Browser code. The default browser is not the end of the road just the current result of our learning. We are working on packages meta data and projects but it takes time.
Iported the package browser to Squeak and reorganized their system once, but people continued to add top-level categories to make finding their code easier. I tried to add the facility to the Pharo browser a year or so ago, and gave up because I couldn't figure how out how to subclass and refine the existing browser framework (and the fact that it seems to be under construction). We should do a pass on it. Now to me the sith pane is not the right way to me. Did you see that there are tags inside packages. BTW Pharo packages are real objects not string comparisons and it took us time to make this changes.
Why do you still use the (terrible, IMHO) Squeak graphics and UI packages (Morphic, Balloon, etc)? It appears that new mostly-redundant systems are still being added to replace these, right?
Give me 5 Million $ and you will see. Pharo will not look like it is. We are not Alan Kay to raise money.
Can't someone reimplement the VisualWorks "Wrapper" UI framework (or something like it) on top of OpenGL contexts as in VW? It's help up pretty well after over 25 years. (David Leibs and I toasted it just last December in Australia.) We have Spec which is a Wrapper frmeworks but there are plenty of space for improvements. And we are WORKING on OUR FREE time on making Athens (vector graphics API supporting different back ends) fully rendering the system. In fact nicolai hess is pushing this massive effort.
How many engineers were working for free in VisualWorks? How many people were paid? So far we got three engineers working in Pharo for 3 years.
How does a newbie learn what all the new packages are for? Glamour, Ring, AsmJit, Zinc, etc. are neat names, but if they're not part of higher-level packages it makes navigating the system (and even figuring out what they're for) pretty difficult. We know. We started to add meta data to package and based on that we want to display the package description. But days here are only 24 hours.
Are there any benchmarks of the current VMs compared to VisualWorks? The last time I used Squeak (a few years ago) it was still pretty slow. I have a real-time event scheduler in Siren that I use to schedule MIDI, so I can run "drum roll" tests to see how the VM performs. check Cog VM. Now there is Spur a new memory manager coming along and it will speed things. Read the blog of clement bera or eliot miranda. Then clement is working on Sista an image level inliner and optimizer and it will bring really new perspective.
How does Pharo handle user primitives or foreign function calls? Is anyone maintaining the old SWIG implementation of Smalltalk? I used it quite a bit to have Smalltalk code create and manage C++ signal processing graphs in the past. SWIG is still going strong, and it's embarrassing that there's no mention at all of Smalltalk on the SWIG pages. Ronie Saldago did a SWIG package.
I'm not trying to start a fight, and I really did like the initial Pharo mission statement of making a tighter, cleaner open-source ST80 implementation.
We are doing it. This is just that you do not see it. Each commit produces before integration a 3mb image shrunk automatically.
Is that dream still what motivates the community? More than ever. We have a now a dependency analyser browser developed by a student we regularly addressed worng dependency. If just takes time and concentration.
If yes, where are the minimalists hiding? We have 11k images fully bootstrap (doing just 2+4 ). Now modular does not means that it has to be minimal. We got a 60 k image that only does beep without a compiler... so not really useful.
We are working on it systematically. Now we should - not confuse ui concerns and the system - code quality is not something that can be displayed - when we use a class from a large package we import all the classes of that packages so merging packages is the wrong approach. - modularity without maps does not work and we should keep maps of working package sets coherent when a change happen. Stef
Stephen Pope HeavenEverywhere Media and FASTLabInc.com <http://FASTLabInc.com> Santa Barbara, CA USA
--
Stephen Travis Pope Santa Barbara, California, USA http://HeavenEverywhere.com <http://HeavenEverywhere.com/>
Looking at Pharo, it appears to me to be suffering the same bloat issues as Squeak.
Well if you say that it is that you are just looking at the tip of iceberg. This is not for fun that we are massively working on cleaning dependencies and removing wrong code or rewriting it. In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now. Bootstrapping means a lot in term of quality. But we have some work to get there and we are busy with our real work (publishing papers).
I think the problem is that people always look at an artefact as âthis what they wantâ as opposed to âthis is just an imperfect snapshot of steps towards what we wantâ. e.g. Morphic still is a *mess*. We have some things started (e.g. Anthens) that will, when they are finished, allow us to simplify things. But right now they are just duplication. Some of the things are just âscaffoldingâ for better solutions in the future. So Pharo4 is just a snapshot of a tiny increment. Pharo5 will be another. And so on. One thing one needs to see is that only the things that are done are done. This is sometimes to exhausting: even the most trivial, obvious thing needs someone to actually do it. Marcus
On 06.02.2015 09:33, stepharo wrote:
In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now.
GNU Smalltalk does just that, if it doesn't find an image, it will be bootstrapped by using the shipped .st fileouts. A bit of cheating is involved, a compiler & initialization is implemented on the VM side. So I would say "there are no Smalltalk that are able to do that right now the way we want to do it" :-P (Pissing at the door contest, to refer to another unquoted metaphor :-D)
Well, but imagine how complex that bootstrap becomes when you want to add to your classes: - traits - layouts - slots ... And expressing all that in C also :) El Fri Feb 06 2015 at 10:47:19 AM, Markus Fritsche <mfritsche@reauktion.de> escribió:
On 06.02.2015 09:33, stepharo wrote:
In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now.
GNU Smalltalk does just that, if it doesn't find an image, it will be bootstrapped by using the shipped .st fileouts.
A bit of cheating is involved, a compiler & initialization is implemented on the VM side.
So I would say "there are no Smalltalk that are able to do that right now the way we want to do it" :-P
(Pissing at the door contest, to refer to another unquoted metaphor :-D)
On 06.02.2015 10:52, Guillermo Polito wrote:
Well, but imagine how complex that bootstrap becomes when you want to add to your classes:
- traits - layouts - slots ...
And expressing all that in C also :) I don't want to imply it's easy.
I once tried to decompose a squeak image, serialize the contents and then try to create a new working environment from that. I finaly gave up when I got { "One step forth", "Two steps forth", "One step back", "Two steps back"}* in any number of combinations... The image is a a) crafted artefact, not a b) generated one, but I think pharo is on a good path from a => b.
On Feb 6, 2015, at 1:52 AM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Well, but imagine how complex that bootstrap becomes when you want to add to your classes:
- traits - layouts - slots ...
And expressing all that in C also :)
Surely the bootstrap doesn't have to be expressed in C?!?! It can be expressed in Smalltalk and still be a bootstrap right?
El Fri Feb 06 2015 at 10:47:19 AM, Markus Fritsche <mfritsche@reauktion.de> escribió:
On 06.02.2015 09:33, stepharo wrote:
In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now.
GNU Smalltalk does just that, if it doesn't find an image, it will be bootstrapped by using the shipped .st fileouts.
A bit of cheating is involved, a compiler & initialization is implemented on the VM side.
So I would say "there are no Smalltalk that are able to do that right now the way we want to do it" :-P
(Pissing at the door contest, to refer to another unquoted metaphor :-D)
El Fri Feb 06 2015 at 4:30:10 PM, Eliot Miranda <eliot.miranda@gmail.com> escribió:
On Feb 6, 2015, at 1:52 AM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Well, but imagine how complex that bootstrap becomes when you want to add to your classes:
- traits - layouts - slots ...
And expressing all that in C also :)
Surely the bootstrap doesn't have to be expressed in C?!?! It can be expressed in Smalltalk and still be a bootstrap right?
:) Hahaha, that was my point. Expressing it in C would be a mess. That's why we do it in Smalltalk.
On Fri, 2015-02-06 at 10:47 +0100, Markus Fritsche wrote:
On 06.02.2015 09:33, stepharo wrote:
In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now.
GNU Smalltalk does just that, if it doesn't find an image, it will be bootstrapped by using the shipped .st fileouts.
Smalltalk/X does that too. It does not even need .st fileouts at bootstrapping time to come up without an image. Jan
A bit of cheating is involved, a compiler & initialization is implemented on the VM side.
So I would say "there are no Smalltalk that are able to do that right now the way we want to do it" :-P
(Pissing at the door contest, to refer to another unquoted metaphor :-D)
I have a few questions:
Why don't you all use a 6-paned browser (called the package browser in Squeak) and control the introduction of top-level meta-categories?
Because you have tags and you can filter packages.
@Stephen, I don't know of the six panelled browser you refer to, but presumably the tree list in the package pane of Pharo's System Browser accounts for one of those two of those six panes e.g. expand the AST-Core package ? @General, btw is it possible to have more levels in the package pane, so that all the AST packages appear under a single first level entry "AST" ?
I really did like the initial Pharo mission statement of making a tighter, cleaner open-source ST80 implementation.
@Stephen, Do you refer to Pharo's general mission or the Pharo Vision document [1] which details a few specific items targeted for improvement, noting that several of those items have already been completed. [1] https://gforge.inria.fr/frs/download.php/30434/*PharoVision*.pdf cheers -ben
2015-02-06 17:05 GMT+01:00 Ben Coman <btc@openinworld.com>:
@General, btw is it possible to have more levels in the package pane, so that all the AST packages appear under a single first level entry "AST" ?
Yes @Ben, but it's not yet in Nautilus. I have a few experiments in that in AltBrowser, such as: - pre-existing hierarchical categories for packages (with about 5 to 20 entries), - naming-based matching (i.e. all AST packages are under AST), [image: Images intégrées 1] - catalogKeyword-based categories (for configurations with keyword entries, they are moved in the right top-level package category), - configuration naming based category creation (see above), and - user adjustable hierarchies (i.e. you can reorganize the tree if you prefer and save it as a setting). Some of it needs some improvement, because configurations are often not that well organised (many don't have keywords at all), naming conventions in configurations aren't reliable, and I don't grok Monticello/Metacello well enough to explore configurations and baselines the way Versionner does. Bringing that to Nautilus may not be that easy. The left pane is fairly narrow, and not very tall due to the filter box (which could auto-hide instead of being allways there). The same goes for the 6 panes idea: it's very wide and, compared to the past, we're dealing with longuer entries (icons, indentation) which translate into larger panes. Thierry
participants (15)
-
Andreas Wacknitz -
Ben Coman -
Eliot Miranda -
Esteban Lorenzano -
Guillermo Polito -
Jan Vrany -
Marcus Denker -
Markus Fritsche -
phil＠highoctane.be -
Sean P. DeNigris -
Serge Stinckwich -
stepharo -
Stephen Travis Pope -
Sven Van Caekenberghe -
Thierry Goubier