[Pharo-users] Re: Wow - Chat GPT understands Smalltalk

[giorgio ferraris]

it's interesting to see how the answer changes with only a small change on
the question:

(1 to: 100 by: 4) reject: [:i | i isOdd]

gives:

The code creates a collection of numbers from 1 to 100, incrementing by 4
at each step using the to:by: message. It then applies the reject: message
to this collection, which returns a new collection containing all elements
for which the given block evaluates to false.

In this case, the block is [i | i isOdd], which checks whether a given
number i is odd using the isOdd method. So the result of the entire
expression is a collection of all even numbers between 1 and 100 that are
divisible by 4.

ciao

giorgio


On Wed, Mar 15, 2023 at 8:07 AM Tim Mackinnon  wrote:

> Of course everyone is talking about ChatGPT, and I saw a post to
> ExplainCode and didn’t expect it to understand Smalltalk, so was impressed
> that it does! Presumably the Tonel Smalltalk code on GitHub has helped
> along with numerous articles?
>
> Try it out: https://whatdoesthiscodedo.com/
>
> I gave this simple example: (1 to: 100 by: 3) reject: [:i | i isOdd]
>
> And got this (neat eh):
>
> The code above is written in the programming language Smalltalk.
>
> It creates a collection of numbers from 1 to 100, incrementing by 3 at
> each step. This is done using the "to:by:" construct where the starting
> value is 1, the ending value is 100, and the increment is 3.
>
> The resulting collection is then filtered using the "reject:" method,
> which takes a block of code as an argument. In this case, the block checks
> whether each element (denoted by the variable i) is odd by using the
> "isOdd" method. If an element is odd, it will be rejected from the
> collection.
>
> So, the final result is a collection of all even numbers from 1 to 100,
> incrementing by 3 at each step.
> Share this explanation with colleagues: whatdoesthiscodedo.com/g/a0ec56e
>

[Pharo-users] Re: Pharo concurrency: select on socket or file IO

[giorgio ferraris]

Hi, Vince,

I don't know exactly Pharo, but when you fork a process, it becomes
an independent thread of work. So in that process you can send your
async call and wait for a response and then do the work. All inside the
forked process.
It's the smallalk's scheduler that will take care of passing control to
other available (green) threads
So it's not clear from me what you need. If you have many forked processes,
each one will do is work up to the end. No need to resume it from outside.

hth
ciao

giorgio



On Thu, Jul 22, 2021 at 8:57 AM  wrote:

> Can the Pharo VM or a library do a “select” on a collection of processes
> waiting on a socket or file IO? Something like
> https://man7.org/linux/man-pages/man2/select.2.html, or
> https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-select
> .
>
> Say I have a bunch of forked processes and some will get blocked waiting
> for IO. I would put the blocked connections/processes in a collection and
> non-blocked processes can continue to do useful work. At some appropriate I
> would do a select on the blocked processes and resume those that are done.
>
> Vince
>

[Pharo-users] Re: We haven't had a design debate in a while - thoughts on CD.buy article...

[giorgio ferraris]

Hi, Russ,
I feel better after reading your mail :)
That's the way I modeled and still model things in my (long...) developer
life, so I felt a bit strange after reading that discussion

ciao

giorgio



On Fri, Apr 16, 2021 at 3:45 PM Russ Whaley  wrote:

> Wow, I must be missing a whole lot of context in that discussion...
> (instant reaction as well, lol)
>
> - a product (CD, book, etc.) does not 'buy' - it can be bought, sure, but
> it has no buying action.  Even in another context a CD does not 'play'...
> aMusicPlayer.play(aCD).
> - However, a customer can 'buy' a product...
>
>- customer.buy(aCD) -or-
>- customer.addToCart(aCD)
>- customer.checkOut(aCart)
>- Invoice.new(aCart), etc.
>
> - ... but the CD doesn't DO anything.
>
> - I get the idea that different products might have different behaviour
> when they are 'bought' - but these are, in this example, fulfillment - not
> the 'buy' action...
>
>- aCDstream might be set for download
>- aCDphysical might be set to physically pull off a shelf and ship
>- aCDcare might send an email on warranty, whatever... but let's name
>it better than 'buy' :)
>
> Tim, thanks for the link - I'm always trying to expand my thinking about
> object modeling - discovering cool ways/things others are thinking
> about...  Now I have to go dust off all my old POS (point of sale, not
> piece of s#) code and see how poorly I may have modeled those
> environments!!
>
> Thanks for the morning diversion!  Cheers.
>
> On Fri, Apr 16, 2021 at 8:53 AM Esteban Maringolo 
> wrote:
>
>> I saw a tweet about that, and I think that the example is misleading,
>> maybe intentionally so.
>>
>> I don't think anybody would model it that way, in any case you'd have
>> aProduct.buy() or aProduct.addToCart(aCart).
>>
>> If you think it with the typical dog.bark() it certainly makes more sense
>> than bark(dog).
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>>
>> On Fri, Apr 16, 2021 at 5:20 AM Tim Mackinnon  wrote:
>>
>>> Hi guys - someone pointed out this article from a UK colleague which
>>> seems to be causing a flurry of discussion - but I always like the insights
>>> of this group. I had an instant reaction when I read it - but curious what
>>> people here think in 2021.
>>>
>>>
>>> https://www.linkedin.com/posts/jasongorman_the-year-is-2021-and-people-still-think-activity-6787650079764303872-SJzz
>>>
>>> Tim
>>>
>>
>
> --
> Russ Whaley
> whaley.r...@gmail.com
>

Re: [Pharo-users] Corona virus

[giorgio ferraris]

Ciao, Dario,


take care of you. Bergamo is on a very bad situations.

giorgio

On Sat, Mar 14, 2020 at 2:53 PM dario.trussardi65 <
dario.trussard...@gmail.com> wrote:

> Ciao,
> be very careful ... it's very dangerous ...
> here in Bergamo it's a disaster.
> We are losing our grandparents like leaves falling from the tree 
> Take all precautions  Don't underestimate the situation.
> See you soon
> Dario
>

Re: [Pharo-users] Another Smalltalk Poll

[giorgio ferraris]

seems pretty complete :)
giorgio

On Wed, Jan 29, 2020 at 2:18 PM Richard Kenneth Eng <
horrido.hobb...@gmail.com> wrote:

> Any feedback?
>
> [image: image.png]
>

Re: [Pharo-users] [ANN] Pharo 8.0 Released!

[giorgio ferraris]

after long time, I downloaded and opened a Pharo image.
Seems you did a great job on these years!!

giorgio



On Tue, Jan 21, 2020 at 10:00 AM Norbert Hartl  wrote:

> Great work and many thanks to all that supported!!
>
> Norbert
>
>
> Am 20.01.2020 um 19:01 schrieb ducasse :
>
> I would like to also thanks all the consortium members and the association
> members so their continuous
> support. In addition we would like to thank SchmidtPro and Lifeware for
> the contracts we sign to improve Pharo.
> Pharo 80 and Pharo 90 will strongly benefit from this effort.
>
> S.
>
> On 20 Jan 2020, at 14:23, Esteban Lorenzano  wrote:
>
> Dear World and dynamic language lovers:
> The time has come for Pharo 8.0 !
> Pharo is a pure object-oriented programming language and a powerful
> environment, focused on simplicity and immediate feedback.
>
> Here are the key highlights of this release:
>
>- The 64-bit version has become the recommended version for Windows as
>it was for Unix and OSX.
>- Iceberg, the git client for Pharo, reached its version 1.6.5 with
>several improvements and bugfixes.
>- Calypso, Pharo’s system browser has new and better refactoring
>integrations and AST-based suggestions for class definitions.
>- The unified foreign function interface (UnifiedFFI) has been
>improved with more support for literal objects, better type coercions, and
>more documentation.
>-
>
>Several speed improvements in code searches and compilation.
>
> In addition, this version includes several previews of new tools such as
> the Spec2 GUI framework with native widget integration and the new DrTests
> test analysis tool and opens the door for the upcoming headless VMs for
> servers and non-blocking FFI.
> These are just the more prominent highlights, but the details are just as
> important. We have closed a massive amount of issues: 2805 issues!
> A comprehensive changelog can be found at
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo80ChangeLogs.md
> 
> ).
> While the technical improvements are significant, still the most
> impressive fact is that the new code that got in the main Pharo 8.0 image
> was contributed by more than 100 people.
> Pharo is more than code. It is an exciting project involving energetic
> people. We thank all the contributors to this release:
> Serge Stinckwich, Myroslava Romaniuk, Hilaire Fernandes, Alexandre Bergel,
> David Bajger, Sean DeNigris, Theodore Moen, Dayne Guerra Calle, Juraj
> Kubelka, Max Leske, Santiago Jose Dandois, Alistair Grant, Sabine Mana,
> Chia Yu, Stephan Eggermont, Milton Mamani, Pavel Krivanek, Ben Coman,
> Marcus Denker, Pierre Misse, Christophe Demarey, Allex Oliveira, Andreina
> Cota, Theo Rogliano, Clément Dutriez, Quentin Ducasse, Cyril Ferlicot,
> Cameron Bierwagen, Marek Niepieklo, Clotilde Toullec, Esteban Lorenzano,
> Vincent Blondeau, Danil Osipchuk, Eiichiro Ito, Noury Bouraqadi, Oleksandr
> Zaytsev, Jason Riggs, Alain Plantec, Kasper Osterbye, Leonardo Cecchi, Chi
> Huynh, Santiago Bragagnolo, Antonio Pierro, Pablo Tesone, Tim Mackinnon,
> Wesley Duerksen, Wilfred Hughes, John Brant, Evelyn Cusi Lopez, Manuel
> Leuenberger, Thomas Dupriez, Norbert Hartl, Torsten Bergmann, Gabriel Omar
> Cotelli, Carlo Teixeira, Guille Polito, Torsten Bergman, Damien Pollet,
> Holger Hans Peter Freyther, Julio Ripoll, Carolina Hernandez Phillips,
> Julien Delplanque, Hugo Lasnier, James Foster, Will Hensel, Erik Stel, Sven
> Van Caekenberghe, Martín Dias, Tomohiro Oda, Konrad Hinsen, Sébastien
> Roccaserra, Stéphane Ducasse, Denis Kudriashov, Ellis Harris, Steven Costiou
> (If you contributed with Pharo 8.0 development in any way and we missed
> your name, please send us a mail and we will add you).
> Enjoy!
> The Pharo Team
> Try Pharo: http://pharo.org/download 
>
> Learn Pharo: http://pharo.org/documentation
> 
>
>
> If you cannot see this, follow this link:
> http://pharo.org/news/pharo8.0-released
>
>
>
>

Re: [Pharo-users] [ANN] Phoedown - Markdown to HTML

[giorgio ferraris]

Hello,
first of all, have a wonderful 2020..
sorry for jumping in, I'm not a contributor to Pharo,  and actually never a
user of it ( when I work in Smalltalk, I use VW mostly, and still need to
find  the time to try Pharo seriously), but I do work in Smalltalk (and
Pharo is a dialect of) from early 80'... and , as for many of you,
Smalltalk is not the only language I use (I wish it was the most used, but
not the only one, because one tool is not enough).
Well, the idea that all should be done in Smalltalk seems to me something
that us as a community have had as a goal from day one, but, are us sure
it's not something that reduce the power of Smalltalk instead of allowing
broader adoption?

   - First, there are lots of libraries and tools already well written,
   maintained and with full documentation. Why to reinvent the wheels if we
   can integrate them seamlessly?
   - Second: Smalltalk is not the fastest language out there, there are
   works that are not to be developed in Smalltalk. If we develop in Smalltalk
   something very CPU intensive we just made bad advertising for the language.


Smalltalk is at is  best for modelling difficult problems. Look at Python,
it's very popular between  Data Scientist, but it just expose in a nice way
an interface to Macchine Learning libraries, For example TensorFlow has a
lot of optimised c++ code inside. Python made easy to interface with C like
languages, and it has good modelling capabilities, so it was chosen.  But
Smalltalk is better on the latter, this is a campground we should dominate,
instead we are absent. And Pharo, being open source, could have been a good
player in this field.
If we spend our time to reinvent the wheel  we can't get to far ..
Look at Node.js, you can find libraries for connecting everything, people
doesn't rewrote everything in JS/ So if you work in Node, you are fast at
building stuff not because of the power of the language, but because to the
libraries you can pick from the shelf and use.

So I think a wonderful and easy integration framework is time better spent
that redoing something already well done on other languages. Object are for
reuse, but we try to rebuild...
And on top of the framework, lot of smalltalk classes for an easy usage of
the outside work already done.
Obviously, all I said is not valid if Smalltalk is considered only an
experimental language or a playground, but this was, and probably still is,
the place for Squeak.  If I remember well, Pharo was born for industrial
grade application...


Sorry for this rant, but I liked Smalltalk from day one, the day I read the
famous Byte's  article, and  still try to understand why it's not the
number one language, but I think we, as a community, did a lot on the wrong
direction.
BTW: I still like Smalltalk a lot and really appreciate the work done by
all of the Smalltalk communities.

again, have a wonderful year

giorgio




On Fri, Jan 3, 2020 at 4:55 PM Ramon Leon  wrote:

> On 2020-01-02 10:56 a.m., Sean P. DeNigris wrote:
> > While I dream of a world where everything is in-image as pure Smalltalk,
> > given the reality of limited manpower, I think of outside library use as
> a
> > way to "cheat" and get a lot more from that limited engineering resource.
>
> Agree, I've used the original Markdown.pl implementation for years same as
> I would any other shell script, via OSProcess
>
> markdown: someContent
>   ^UnixProcess pipeString: someContent throughCommand: (FileDirectory
> default fullPathFor: 'Markdown.pl')
>
> Never saw a need to rewrite what already works in its original form.
>
> --
> Ramón León
> VP of Technology
> Alliance Reservations Network
>
>

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[giorgio ferraris]

for what I know  it's the way it's integrated with the underlain OS.  On
windows things are much,  much  better.

*VW emulates GUIs well, but I would not expect it to beat native*.   I
would restate it as : I would not expect native to be slower that
emulated  :) seems the same, but not exactly...

ciao

giorgio

I hope to have time to look again at Pharo one of these days. But time is
always a scarce resource :)

On Wed, Oct 9, 2019 at 4:17 AM Shaping  wrote:

> Regarding native widget, on the VW side the usage on them brought
> slowness on the OSX platform. Windows platform is speedy, but OSX platform
> is slower using native widget than with emulated ones.
>
> So native widget alone are not always a solution.
>
>
>
> That’s interesting and unexpected (I don’t use OSX).  I would think that
> something is wrong with the VW native implementation or interface to it.
> VW emulates GUIs well, but I would not expect it to beat native.
>
>
>
> Shaping
>
>
>
> On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano 
> wrote:
>
>
>
>
>
> On 7 Oct 2019, at 12:39, Shaping  wrote:
>
>
>
> I haven't seen is the instability of the VM you mention, it has worked
> pretty well for my average use, although the UX is not straightforward.
>
>
>
> Yes, lots of redirection and extra steps.  Many degrees of freedom.
> Seemingly no good default “happy” path to simplify things a little before
> you start to investigate the variations/choices.
>
>
>
> > The other thing that keeps me planted firmly in VW is the sheer speed of
> it.
>
>
>
> I don't know if there are recent benchmarks, but I've felt Pharo to be
> really fast compared to VW when it comes to computing.
>
>
>
> I’ve don’t plenty of informal comparative testing mostly with the GUI.
>   I’ve used VW continuously for 29 years and Pharo on and off since 2006.
> (I’m really trying to port, but I keep failing to do it; getting closer).
>  VW is still noticeably quicker in GUI responsiveness, in most cases.  One
> big difference is the Pharo HTTP client, with all those wonderful
> primitives.  It’s about *twice as fast* as VW’s.  Bravo.  I meant to tell
> that to Sven recently, and forgot.
>
>
>
> > Pharo looks generally much better, but it’s mushy, and that’s a
> problem.  VW is not.
>
>
>
> Working regularly with VW or VAST when I go back to Pharo the "mushiness"
> is significantly noticeable, but if you open a Pharo 3 image (or even Pharo
> 4) you'll feel it really "snappy", but of course you'll lose all the
> improvements since then; and that's the current tradeoff.’
>
>
>
> Yeah, I guess all the new slick GUIs are a bit heavier.  This machine is
> just okay for speed –2.7 GHz Xeon, but VW feels okay.  Pharo tends to put
> me slowly to sleep with the tiny but noticeable lags here and there.   I’m
> very fond of GT.  Beautiful.   Not sure what to do go get the GUI quickness
> back.  Maybe you  guys are waiting for the new GUI framework(s) to firm
> up?   I tried Cuis, and was not impressed.  It’s too lean/Spartan and still
> not very fast (slower in some ways than Pharo).  I like the Pharo
> creature-comforts (who wouldn’t?).
>
>
>
> I never understood the reason for the incremental slowdown, it is even
> present in "modern" tools such as GTToolkit.
>
>
>
> Yes, it’s like a creeping disease.  Lol
>
>
>
> Another thing I miss enough to want to implement (or fake-out somehow) is
> Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to
> 6 up at once, if I’m behaving, and as many as 20 if I’m not.   Looking
> about for the tabs at the bottom to click is not nearly as fun as
> Alt-Tabbing.  Maybe I could emulate Alt-Tab with Alt-Shift-Tab—a bit of a
> finger twister, but it might work.
>
>
>
> > Gestural dynamics are very quick, well under 100 ms latency, often less
> than 20 ms.
>
> > I’m seeing 100, 150, and 200 ms regularly in Pharo.  It’s too mushy, and
> that slows the mind.
>
> > Any developer understands this, whether he talks about it or not.
>
>
>
> This is true, below 20ms is ideal, and top-notch CLI terminals are
> benchmarking this as a selling point (using stuff like
> https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++
> measure sub 10ms latency.
>
>
>
> Indeed.
>
>
>
> My whole nervous system definitely feels this speed effect and starts to
> thought-glide better below these tiny latencies.  I’m sure many reading
> this have had similar experiences.  Something similar happens when you are
> fortunate enough to use a machine with extremely fast striped SSD drives,
> where *you literally don’t wait for anything*, except the bloody
> internet.  This doesn’t just change the speed at which you do the work.  It
> reorganizes your mind and skills in ways you had not anticipated because
> you can flow so much more quickly, making connections further forward and
> backward in your thought stream.  My point is that if the speed and
> low-latencies are made a priority, we can attract users just on this basis
> alone.  Even I would be 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[giorgio ferraris]

Hello,

Regarding native widget, on the VW side the usage on them brought
slowness on the OSX platform. Windows platform is speedy, but OSX platform
is slower using native widget than with emulated ones.
So native widget alone are not always a solution.

ciao
giorgio

On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano 
wrote:

>
>
> On 7 Oct 2019, at 12:39, Shaping  wrote:
>
> I haven't seen is the instability of the VM you mention, it has worked
> pretty well for my average use, although the UX is not straightforward.
>
> Yes, lots of redirection and extra steps.  Many degrees of freedom.
> Seemingly no good default “happy” path to simplify things a little before
> you start to investigate the variations/choices.
>
> > The other thing that keeps me planted firmly in VW is the sheer speed of
> it.
>
> I don't know if there are recent benchmarks, but I've felt Pharo to be
> really fast compared to VW when it comes to computing.
>
> I’ve don’t plenty of informal comparative testing mostly with the GUI.
>   I’ve used VW continuously for 29 years and Pharo on and off since 2006.
> (I’m really trying to port, but I keep failing to do it; getting closer).
>  VW is still noticeably quicker in GUI responsiveness, in most cases.  One
> big difference is the Pharo HTTP client, with all those wonderful
> primitives.  It’s about *twice as fast* as VW’s.  Bravo.  I meant to tell
> that to Sven recently, and forgot.
>
> > Pharo looks generally much better, but it’s mushy, and that’s a
> problem.  VW is not.
>
> Working regularly with VW or VAST when I go back to Pharo the "mushiness"
> is significantly noticeable, but if you open a Pharo 3 image (or even Pharo
> 4) you'll feel it really "snappy", but of course you'll lose all the
> improvements since then; and that's the current tradeoff.’
>
> Yeah, I guess all the new slick GUIs are a bit heavier.  This machine is
> just okay for speed –2.7 GHz Xeon, but VW feels okay.  Pharo tends to put
> me slowly to sleep with the tiny but noticeable lags here and there.   I’m
> very fond of GT.  Beautiful.   Not sure what to do go get the GUI quickness
> back.  Maybe you  guys are waiting for the new GUI framework(s) to firm
> up?   I tried Cuis, and was not impressed.  It’s too lean/Spartan and still
> not very fast (slower in some ways than Pharo).  I like the Pharo
> creature-comforts (who wouldn’t?).
>
> I never understood the reason for the incremental slowdown, it is even
> present in "modern" tools such as GTToolkit.
>
> Yes, it’s like a creeping disease.  Lol
>
> Another thing I miss enough to want to implement (or fake-out somehow) is
> Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to
> 6 up at once, if I’m behaving, and as many as 20 if I’m not.   Looking
> about for the tabs at the bottom to click is not nearly as fun as
> Alt-Tabbing.  Maybe I could emulate Alt-Tab with Alt-Shift-Tab—a bit of a
> finger twister, but it might work.
>
> > Gestural dynamics are very quick, well under 100 ms latency, often less
> than 20 ms.
> > I’m seeing 100, 150, and 200 ms regularly in Pharo.  It’s too mushy, and
> that slows the mind.
> > Any developer understands this, whether he talks about it or not.
>
> This is true, below 20ms is ideal, and top-notch CLI terminals are
> benchmarking this as a selling point (using stuff like
> https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++
> measure sub 10ms latency.
>
> Indeed.
>
> My whole nervous system definitely feels this speed effect and starts to
> thought-glide better below these tiny latencies.  I’m sure many reading
> this have had similar experiences.  Something similar happens when you are
> fortunate enough to use a machine with extremely fast striped SSD drives,
> where *you literally don’t wait for anything*, except the bloody
> internet.  This doesn’t just change the speed at which you do the work.  It
> reorganizes your mind and skills in ways you had not anticipated because
> you can flow so much more quickly, making connections further forward and
> backward in your thought stream.  My point is that if the speed and
> low-latencies are made a priority, we can attract users just on this basis
> alone.  Even I would be working harder at improving Pharo (and complaining
> less) if everything were snappy.  I would probably just get on with doing
> the needed tasks.  Interesting how that works.  Speed:  it changes you.  It
> changes the whole game.
>
> > So I’m wondering when the Pharo GUI will snap as well as VW.
>
> Maybe with native widgets there will be a significant speedup, although I
> don't know whether the lag comes from rendering time or from something else.
>
> I would like to know more about the native widgets in Pharo.  Does anyone
> know when this is likely to happen?
>
>
> I know, since I’m doing it :)
> Native widgets (more like “gtk widgets”. This is technically just native
> under linux, but Gtk3 works very well both in Windows and Mac (you just has
> to ship it) 

Re: [Pharo-users] VW vs Pharo Performance

[giorgio ferraris]

hello,

Test seems old, both virtual machines (VW and Pharo) have upgraded in the
meantime.
VW has always been faster that Pharo for what I know, up to recent time.
Recently Pharo changed the vm technology so now it should be much faster,
but I don'r know is faster that VW , so it would be nice to have a up to
date comparison.
Related to Matrix, this is a nice way to have many smalltalk images running
in parallel, but it doesn't seems the case of this test. It requires a
specific way of writing the code, it is not as automatic as  defining a
piece of code "parallel". The thread model of VW and Pharo are still the
same, green thread and (almost) single core systems

ciao

giorgio

On Sat, Aug 31, 2019 at 2:37 PM Sven Van Caekenberghe  wrote:

>
>
> > On 31 Aug 2019, at 13:27, Richard Kenneth Eng 
> wrote:
> >
> >
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-pharo.html
> >
> > Is VisualWorks really faster than Pharo? Why???
>
> The Pharo code is single threaded, single core, while the VW code uses
> something called MatriX.VirtualMachines to create workers that run on
> multiple cores.
>
> Presumably that makes a huge difference.
>
> Also, such parallelism is easy for benchmarks that can be split in
> independent tasks, real world code is a completely different story.
>
> Basically, this is not the same code that is being compared.
>
>
>

Re: [Pharo-users] [Vm-dev] [ANN] Pharo 4.0 is released!

[giorgio ferraris]

Hi, Guys,

you did and absolutely wonderful work!

giorgio ferraris

On Thu, Apr 16, 2015 at 4:14 PM, Johan Fabry jfa...@dcc.uchile.cl wrote:


  On Apr 16, 2015, at 08:38, Sven Van Caekenberghe s...@stfx.eu wrote:
 
 
  On 16 Apr 2015, at 11:55, Tudor Girba tu...@tudorgirba.com wrote:
 
  Great job!
 
  Thank you everyone for the contributions, support and trust.
 
  + 100

 + 100 as well :-)

 Excellent news !!!

 --- Save our in-boxes! http://emailcharter.org ---

 Johan Fabry   -   http://pleiad.cl/~jfabry
 PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-users] [ann] moose 5.0

[giorgio ferraris]

Hi, Guys,

I'm not (yet) working on Pharo (still VW and some VisualSmalltalk in the
few time left free from my main job), but I follow what you do (not just
you but all the community) and I have to admit you (all) work really hard.
Bergel is doing a fantastic job, and your Moose is very nice, etc.
But, I really liked the presentation of the GT stuff, I can understand the
energy you put behind your work.

Great work. I'm happy you are on the ST community and working on the
language (ST) i like the most. Thanks!
 (Oh, I know you don't like to have Pharo called Smalltalk, but I don't
like religion's wars, so that is yet smalltalk, for me).

BTW: Happy Holidays to all.

Giorgio

On Wed, Dec 24, 2014 at 12:09 AM, Tudor Girba tu...@tudorgirba.com wrote:

 We are happy to announce Moose 5.0:
 *http://moosetechnology.org/#install*


 Description
 ---

 This is by far the most extensive Moose release to date. Just take a look
 at these two trailers.
 - Spotter: https://vimeo.com/113832673
 - Inspector: https://vimeo.com/103463364

 The key highlights are:
 - It is based on Pharo 3.0.
 - Roassal2 is a complete reimplementation of the core visual engine of
 Moose.
 - Roassal2 replaced Roassal, EyeSee and Graph-ET, and it features many new
 things including smooth animations, new composeable builders and several
 new layouts.
 - All built-in Moose visualizations use Roassal2.
 - Glamour has been extended with a Pager browser and with Rubric as the
 main text editor.
 - GTSpotter is a new tool that makes it possible to find objects fast.
 - GTInspector saw major usability improvements based on the Pager browser,
 and it now comes with many object specific extensions.
 - GTPlayground provides a new way to handle scripts and when combined with
 GTInspector, it can replace the dedicated easels and editors.
 - Moose Finder has been extended with the ability of handling in place
 visualizations.
 - GTDebugger has been strengthen and was made more robust.
 - PetitParser has been extended with the notion of context which enables
 elegant island parsing.

 A list of issues addressed in this release can be found at:

 http://code.google.com/p/moose-technology/issues/list?can=1q=status=Fixed%20milestone=5.0


 Installation
 ---

 The Moose Suite 5.0 comes for each platform as a separate bundle:
 - *Moose Suite 5.0 for Machttp://moosetechnology.org/res/download/
 moose_suite_5_0-mac.zip
 https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_5_0-mac.zip
 *
 https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_8-mac.zip*
 - *Moose Suite 5.0 for Windowshttp://moosetechnology.org/res/download/
 moose_suite_5_0-win.zip
 https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_5_0-win.zip
 *
 https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_8-win.zip*
 - *Moose Suite 5.0 for Linuxhttp://moosetechnology.org/res/download/
 moose_suite_5_0-linux.zip
 https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_5_0-linux.zip
 *
 https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_8-linux.zip*

 The Moose Suite 5.0 can also be loaded in a Pharo 3.0 image either from
 the Configuration Browser, or by executing the following script:

 ==Gofer new
 ==  smalltalkhubUser: 'Moose' project: 'Moose';
 ==  configuration;
 ==  loadStable


 Happy holidays!
 The Moose team

Re: [Pharo-users] Pharo 3 minor issue

[giorgio ferraris]

it usually happens that way. You test everything and miss something
obvious...

ciao

giorgio


On Thu, May 1, 2014 at 9:24 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 thanks for reporting, I will look at it (super weird that it did not arise
 before :( )

 Esteban

 On 30 Apr 2014, at 20:54, giorgio ferraris giorgio.ferra...@gmail.com
 wrote:

  Hi,
 
  started looking at Pharo after many years.
  First of all, you all did an awesome works, thank you!
  There is a small problems on System Browser
   open image
  open system browser
  choose one class
  select group
  The class side checkbox is enabled, if you check it, you get a wall bak .
  Giorgio
 
  Screen Shot 2014-04-30 at 20.42.03.jpg