April 2018 - Pharo-users - lists.pharo.org

Where do we go now ?

by Benoit St-Jean

Hello guys, Just a quick word to get some things straight because, quite frankly, I really don't know where we're heading. When Pharo started, the goal was to depart from Squeak and do a *major clean up* of all the code, especially Morphic.Â The promise of a new, clean & lean Smalltalk attracted a lot of people.Â And then... I'm looking at the Pharo 7.0 image right now and I just don't get where we're heading.Â Every Pharo release gets bigger, and bigger, and bigger.Â I don't mind the environment getting bigger if it adds functionalities or new tools but that's not quite the case here. LOTS of stuff is just duplicated. Do we really need 2 code completion classes (NECController, NOCController) ?Â Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 compilers (OpalCompiler, Compiler) ?Â Do we really need 8 delay schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ?Â Do we really need 2 inspectors (GTInspector, EyeInspector) ?Â Do we really need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera.Â I could go on, and on, and on... Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 7612 classes.Â Can you see a trend? Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. Pharo 7.0 alpha has 662 preference settings.Â Can you see a trend? Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 alpha has a 47.97 MB image.Â Can you see a trend? Add to that the fact that Pharo is a nightmare when you want to port code.Â Just with the 7.0 release, 61 classes will be deprecated (and lots more to come if you search for the string "deprecated" into the code, most of the time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess classes). You have code that deals with sockets, should you use the old Socket classes or convert everything to Zodiac? And why do we keep both "frameworks" in the image ?Â Pharo hasn't been backward compatible with "old socket classes" a looooooong time ago anyway! You have code that deals with dependencies, should you use the old dependents mechanism or convert everything to announcements? UI speaking, what framework should anyone use ?Â Athens?Â Something else? You have code that deals with streams, should you use the old stream classes or convert everything to Zinc ? And why do we keep both "frameworks" in the image ?Â Pharo hasn't been backward compatible with the old stream classes a looooooong time ago anyway! So what's the plan?Â For instance, should I keep using the Nautilus Browser or I should switch to the Calypso browser and get used to it because Nautilus will be deprecated?Â Or should I just don't care because a third system browser will be added in Pharo 8 just because "it's cool, let's add this one too!" ? Couldn't we just decide on what's "official" and what's a goodie or an external optional tool/package/framework the same way all other Smalltalks do?Â If you say Calypso is the official & supported browser, fine!Â Then just get Nautilus out of the image, create a nice loadable package for it and if someone prefers Nautilus, they'll just have to load it into the image, the same way VW has a gazillion optional tools/packages/frameworks you can load from a parcel! Whenever I get asked a simple question by a newbie like "Oh, which system browser should I use?", quite frankly, I don't know what to answer.Â Did we include Calypso to deprecate Nautilus later?Â Is Calypso just a proof of concept?Â Is it just an optional tool?Â What about all those delay schedulers? Â "I loaded this code from SqueakSource and it just doesn't work".Â Should I help the guy to fix it or just tell him to convert all the code to the corresponding framework in Pharo? Perhaps a little bit of clarity and details about what's coming and what's the plan would be beneficial to a lot of us. ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

April 13, 2018

Re: [Pharo-users] Progress bar for ZnClient>>#downloadTo:

by Ben Coman

You may have guessed I hadn't used Jobs much before. Then I was surprised that I couldn't find much about Jobs in either Pharo By Example, Deep Into Pharo or Enterprise Pharo. >From digging around I made a minimal example I report to help others' searches, and open it for improvement. x := 1. [ [x < 100] whileTrue: [ x := x + 10. 0.1 seconds wait. ] ] forkAt: 30 named: 'worker'. [ :job | [ x < 100 ] whileTrue: [ job current: x. 0.1 seconds wait. ] ] asJob title: 'Work progress...'; min: 0; max: 100; run. cheers -ben On 12 April 2018 at 23:02, Ben Coman <btc(a)openinworld.com> wrote: > > > On 12 April 2018 at 18:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Ben, >> >> You disappoint me, as I would expect you to trace senders/users of >> #signalProgress: ;-) >> > > :P > Yeah I knew I was being slack. I couldn't really follow its operation and > was a bit tired. > Actually maybe part of my confusion is that #signalProgress feels more > like a command than a status. > I've a slight feeling it would be better as #signallingProgress. > > > >> ZnClient only signals certain Notifications which a UI around it should >> deal with. >> >> For example, >> >> [ :bar | >> bar title: 'Downloading Sources...'. >> [ >> ZnClient new >> url: 'http://files.pharo.org/sources/PharoV30.sources'; >> signalProgress: true; >> downloadTo: FileLocator temp ] >> on: HTTPProgress >> do: [ :progress | >> progress isEmpty ifFalse: [ bar current: progress percentage ]. >> progress resume ] ] asJob run. >> > > Thanks, that worked, but its a bit convoluted for my goldfish memory to > remember each time. > I'd expect having that as a convenience method would be useful to many. > > ZnClient > showProgress: 'Downloading sources...' > during: [ :znClient | > znClient url: 'http://files.pharo.org/sources/PharoV30.sources'. > znClient downloadTo: FileLocator imageDirectory ]. > > ZnClient class >> showProgress: title during: clientBlock > |client| > client := ZnClient new. > client signallingProgress: true. > [ :bar | > bar title: title. > [clientBlock value: client] > on: HTTPProgress > do: [ :progress | > progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume ] ] asJob run. > > Easily discoverable as the only class-side method of ZnClient, > and this would also make a useful howto reference. > > > >> But there are other UI approaches as well. > > >> Sven >> > > Thanks for you prompt response. > cheers -ben > > > >> > On 12 Apr 2018, at 11:25, Ben Coman <btc(a)openinworld.com> wrote: >> > >> > I see ZnClient >> downloadTo: >> > calls ZnClient >> downloadEntityTo: >> > which uses #withProgressDo: >> > which indicates a progress bar might appear. >> > >> > But... >> > ZnClient new >> > url: ' https://download.libsodium.org >> /libsodium/releases/libsodium-1.0.16-msvc.zip' ; >> > downloadTo: FileLocator imageDirectory. >> > doesn't show a progress bar. What is the recommended way to display >> one? >> > >> > cheers -ben >> >> >> >

April 13, 2018

Re: [Pharo-users] SmalltalkCI now supports loading tonel-based projects

by Gabriel Cotelli

Framework for testing Smalltalk projects on Linux, macOS, and Windows and on Travis CI and AppVeyor. https://github.com/hpi-swa/smalltalkCI On Thu, Apr 12, 2018 at 2:04 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > What is SmalltalkCI? > > Tonel is a very cool feature as it makes commiting source in file based > repo very friendly, and browsing from from web based UI tools nice too. > > > > Le 07/04/2018 Ã 11:28, Peter UhnÃ¡k a Ã©crit : > >> SmalltalkCI now supports loading tonel-based projects, so feel free to >> start using it. >> >> > -- > Dr. Geo > http://drgeo.eu > > > >

April 12, 2018

Re: [Pharo-users] SmalltalkCI now supports loading tonel-based projects

by Hilaire

What is SmalltalkCI? Tonel is a very cool feature as it makes commiting source in file based repo very friendly, and browsing from from web based UI tools nice too. Le 07/04/2018 Ã 11:28, Peter UhnÃ¡k a Ã©critÂ : > SmalltalkCI now supports loading tonel-based projects, so feel free to > start using it. > -- Dr. Geo http://drgeo.eu

April 12, 2018

Re: [Pharo-users] SmalltalkCI now supports loading tonel-based projects

by Sean P. DeNigris

Stephane Ducasse-3 wrote > Thanks this is good to know because I want to migrate all my projects > and future project to use tonel. +1! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 12, 2018

Re: [Pharo-users] In P7 scrpt variable to tmp when in debugger

by Hilaire

Thanks. Le 12/04/2018 Ã 17:18, Marcus Denker a Ã©critÂ : > I should have a fix ready tomorrow. -- Dr. Geo http://drgeo.eu

April 12, 2018

Re: [Pharo-users] In P7 scrpt variable to tmp when in debugger

by Marcus Denker

> On 12 Apr 2018, at 17:06, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi Marcus, Benoit, > > Nice to know. I was testing in a set up with both .changes and source files. So I was suspecting something like what your described. I can imagine in production code your feature to speed up compilation will be appreciated. For Dr. Geo and Smalltalk sketch, it is better to have variable names. > I should have a fix ready tomorrow. > Thanks > > Hilaire > > Le 12/04/2018 Ã 16:31, Marcus Denker a Ã©crit : >> Hello, >> >> I changed the way code is compiled for #evaluate: to speed it up, but it turns out that having nice vars is actually more important than >> speed in most cases. >> >> I will change this again and just add it as an optional feature (you then can set an option if you need speed, but the default will be to keep the >> var names). >> >> For an intermediate fix, you can change in OpalCompiler>>#evaluate the send of #generate to #generateWithSource. >> >> Marcus > > -- > Dr. Geo > http://drgeo.eu > > >

April 12, 2018

Re: [Pharo-users] In P7 scrpt variable to tmp when in debugger

by Hilaire

Hi Marcus, Benoit, Nice to know. I was testing in a set up with both .changes and source files. So I was suspecting something like what your described. I can imagine in production code your feature to speed up compilation will be appreciated. For Dr. Geo and Smalltalk sketch, it is better to have variable names. Thanks Hilaire Le 12/04/2018 Ã 16:31, Marcus Denker a Ã©critÂ : > Hello, > > I changed the way code is compiled for #evaluate: to speed it up, but it turns out that having nice vars is actually more important than > speed in most cases. > > I will change this again and just add it as an optional feature (you then can set an option if you need speed, but the default will be to keep the > var names). > > For an intermediate fix, you can change in OpalCompiler>>#evaluate the send of #generate to #generateWithSource. > > Marcus -- Dr. Geo http://drgeo.eu

April 12, 2018

Re: [Pharo-users] Progress bar for ZnClient>>#downloadTo:

by Ben Coman

On 12 April 2018 at 18:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ben, > > You disappoint me, as I would expect you to trace senders/users of > #signalProgress: ;-) > :P Yeah I knew I was being slack. I couldn't really follow its operation and was a bit tired. Actually maybe part of my confusion is that #signalProgress feels more like a command than a status. I've a slight feeling it would be better as #signallingProgress. > ZnClient only signals certain Notifications which a UI around it should > deal with. > > For example, > > [ :bar | > bar title: 'Downloading Sources...'. > [ > ZnClient new > url: 'http://files.pharo.org/sources/PharoV30.sources'; > signalProgress: true; > downloadTo: FileLocator temp ] > on: HTTPProgress > do: [ :progress | > progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume ] ] asJob run. > Thanks, that worked, but its a bit convoluted for my goldfish memory to remember each time. I'd expect having that as a convenience method would be useful to many. ZnClient showProgress: 'Downloading sources...' during: [ :znClient | znClient url: 'http://files.pharo.org/sources/PharoV30.sources'. znClient downloadTo: FileLocator imageDirectory ]. ZnClient class >> showProgress: title during: clientBlock |client| client := ZnClient new. client signallingProgress: true. [ :bar | bar title: title. [clientBlock value: client] on: HTTPProgress do: [ :progress | progress isEmpty ifFalse: [ bar current: progress percentage ]. progress resume ] ] asJob run. Easily discoverable as the only class-side method of ZnClient, and this would also make a useful howto reference. > But there are other UI approaches as well. > Sven > Thanks for you prompt response. cheers -ben > > On 12 Apr 2018, at 11:25, Ben Coman <btc(a)openinworld.com> wrote: > > > > I see ZnClient >> downloadTo: > > calls ZnClient >> downloadEntityTo: > > which uses #withProgressDo: > > which indicates a progress bar might appear. > > > > But... > > ZnClient new > > url: ' https://download.libsodium.org/libsodium/releases/ > libsodium-1.0.16-msvc.zip' ; > > downloadTo: FileLocator imageDirectory. > > doesn't show a progress bar. What is the recommended way to display one? > > > > cheers -ben > > >

April 12, 2018

Re: [Pharo-users] In P7 scrpt variable to tmp when in debugger

by Marcus Denker

> On 12 Apr 2018, at 16:10, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > When an executed script throws an error, in the debugger the script lost its variable names and the code is not exactly the same. > > Any idea why? > Hello, I changed the way code is compiled for #evaluate: to speed it up, but it turns out that having nice vars is actually more important than speed in most cases. I will change this again and just add it as an optional feature (you then can set an option if you need speed, but the default will be to keep the var names). For an intermediate fix, you can change in OpalCompiler>>#evaluate the send of #generate to #generateWithSource. Marcus

April 12, 2018