- Pharo-users - lists.pharo.org

Pharo things analog reads ?

by Steven Costiou

Hi, For what i know, raspberry pi boards cannot read analog sensors (which are the most interesting imo), except by connecting to some kind of bridges or to Arduino boards. In the PharoTHings code i see that there are Arduino classes, and also it is based on wiringpi and wiringpi provides support for i2c which is needed to connect to an Arduino and perform analog reads. I'm exploring the wiringpi doc to see if there is an example for that, but in the meantime, would someone already have an example of analog reads with PharoThings, with working code (even simple) ? Steven.

Dec. 17, 2017

Re: [Pharo-users] FLSerialization>>analysisStep too slow?

by Eno

Sure, it's a great news that the leader could give me a hand. I came from Dolphin, not acquainted with pharo configuration, though I knew a lot that it could automize the loading and update. It depended upon Magritte3, Sandstone, and my packages. The store directory need to be changed in other's new image, currently, I set it fixed inside the method, MacOSResolver>>store, WindowsResolver>>store. On new installed image while running up via wordmenu, a new db file need to be created from the tool icon. Thanks. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 17, 2017

Re: [Pharo-users] FLSerialization>>analysisStep too slow?

by Eno

Well, it is just my intent to place related playgrounds, doc, help, and classes/methods, mophic, tool browser etc into domain object dbs of topics/playgrounds trees while exploring the image and studing/writing packages. It's just a convenient help and an working enviornment I made specifically by my interest, not meant to replace the current IDE, using the tricks that the morphic browser would somehow integrate inside to glamour browser. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 17, 2017

Re: [Pharo-users] Pharo Launcher name

by Alexandre Bergel

+1 EnvoyÃ© de mon iPhone > Le 16 dÃ©c. 2017 Ã 20:32, Glenn Hoetker <ghoetker(a)me.com> a Ã©crit : > > I love the Pharo Launcher. But, I find it confusing to have an application called âPharo.appâ. Nothing in that name suggests it is a launcher. It is also very confusing to have an application called âPharo.appâ next to one called âPharo6.1.appâ when they are very different things (at least from a users perspective). > > Has changing the name of the Pharo Launcher to âPharo Launcherâ ever been considered? > > Just a thought. Most of all, thanks for the wonderful tool. > > Glenn

Dec. 16, 2017

Re: [Pharo-users] Pharo Launcher name

by Cyril Ferlicot D.

Le 17/12/2017 Ã 00:32, Glenn Hoetker a Ã©critÂ : > I love the Pharo Launcher. Â But, I find it confusing to have an > application called âPharo.appâ. Nothing in that name suggests it is a > launcher. Â It is also very confusing to have an application called > âPharo.appâ next to one called âPharo6.1.appâ when they are very > different things (at least from a users perspective). > > Has changing the name of the Pharo Launcher to âPharo Launcherâ ever > been considered? > > Just a thought. Most of all, thanks for the wonderful tool. > > Glenn Hi, I agree. I found it confusing on linux to have a "pharo" script to launch the pharo launcher. https://github.com/pharo-project/pharo-launcher/issues/59 -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 16, 2017

Pharo Launcher name

by Glenn Hoetker

I love the Pharo Launcher. But, I find it confusing to have an application called âPharo.appâ. Nothing in that name suggests it is a launcher. It is also very confusing to have an application called âPharo.appâ next to one called âPharo6.1.appâ when they are very different things (at least from a users perspective). Has changing the name of the Pharo Launcher to âPharo Launcherâ ever been considered? Just a thought. Most of all, thanks for the wonderful tool. Glenn

Dec. 16, 2017

Athens error

by Hilaire

Hi, With DrGeo built on image Pharo7.0-64bit-e41f921 Athens error shows up on the canvas (screenshot). The drgeo dev. environment based on the older Pharo7.0-64bit-f82fc36 image does not have this error with the same VM. The DrGeo build removes some pharo package but it is unlikely to produce such error, or so? -- Dr. Geo http://drgeo.eu

Dec. 16, 2017

Re: [Pharo-users] Working directory

by Stephane Ducasse

Now introducing a new name means that all the documentation, books, videos are obsolete. And this is a cost too. On Sat, Dec 16, 2017 at 5:03 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Ben, > > On 15 December 2017 at 22:14, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> >> wrote: >>> >>> Le 15/12/2017 Ã 21:24, Hilaire a Ã©crit : >>> > In P3: >>> > >>> > FileSystem disk workingDirectory >>> > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared >>> > >>> > In P7: >>> > >>> > FileSystem disk workingDirectory >>> > =>File @ /home/hilaire >>> > >>> > Is it a bug? >>> > >>> >>> Hi! >>> >>> In Pharo 3 >>> >>> workingDirectory = imageDirectory. >>> >>> In Pharo 7 >>> >>> workingDirectory = directory from where Pharo was launched. >> >> >> just double-checking... >> with equivalent shell commands... >> $ DIR1 = `pwd` >> $ $DIR2/pharo $DIR3/Pharo.image >> >> Pharo 3 ==> workingDirectory = $DIR3 >> Pharo 7 ==> workingDirectory = $DIR1 >> ? >> >> I wonder for such a semantic API change it might be good to >> introduce #workDirectory and deprecate #workingDirectory >> so the need for user-devs to change their code is more explicit. >> It might make easier to have an auto-conversion rule #workingDirectory ==> >> #imageDirectory, >> and make it harder to shoot yourself in the foot producing cross-platform >> libraries. >> >> cheers -ben > > I raised this concern when the change was first proposed. The only > responses I saw were that it doesn't matter. > > Also, prior to Pharo 6, it was possible to change the working > directory, so programs shouldn't have assumed that workingDirectory = > imageDirectory. > > >> Perhaps we should only refer to the operating system's current working directory. >> (Sorry I'm not in a position to dig into that right now) > > Rajula wrote the code to allow the working directory to be updated, > i.e. calling setwd(). I don't think it made it in to the submitted > patch, but it obviously could be added in future. > > The working directory is cached (in DiskStore > DefaultWorkingDirectory), but currently there is no way of changing > the value, so effectively it is always the OS cwd. > > Cheers, > Alistair >

Dec. 16, 2017

Re: [Pharo-users] Working directory

by Alistair Grant

Hi Ben, On 15 December 2017 at 22:14, Ben Coman <btc(a)openinworld.com> wrote: > > > On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> > wrote: >> >> Le 15/12/2017 Ã 21:24, Hilaire a Ã©crit : >> > In P3: >> > >> > FileSystem disk workingDirectory >> > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared >> > >> > In P7: >> > >> > FileSystem disk workingDirectory >> > =>File @ /home/hilaire >> > >> > Is it a bug? >> > >> >> Hi! >> >> In Pharo 3 >> >> workingDirectory = imageDirectory. >> >> In Pharo 7 >> >> workingDirectory = directory from where Pharo was launched. > > > just double-checking... > with equivalent shell commands... > $ DIR1 = `pwd` > $ $DIR2/pharo $DIR3/Pharo.image > > Pharo 3 ==> workingDirectory = $DIR3 > Pharo 7 ==> workingDirectory = $DIR1 > ? > > I wonder for such a semantic API change it might be good to > introduce #workDirectory and deprecate #workingDirectory > so the need for user-devs to change their code is more explicit. > It might make easier to have an auto-conversion rule #workingDirectory ==> > #imageDirectory, > and make it harder to shoot yourself in the foot producing cross-platform > libraries. > > cheers -ben I raised this concern when the change was first proposed. The only responses I saw were that it doesn't matter. Also, prior to Pharo 6, it was possible to change the working directory, so programs shouldn't have assumed that workingDirectory = imageDirectory. > Perhaps we should only refer to the operating system's current working directory. > (Sorry I'm not in a position to dig into that right now) Rajula wrote the code to allow the working directory to be updated, i.e. calling setwd(). I don't think it made it in to the submitted patch, but it obviously could be added in future. The working directory is cached (in DiskStore DefaultWorkingDirectory), but currently there is no way of changing the value, so effectively it is always the OS cwd. Cheers, Alistair

Dec. 16, 2017

Re: [Pharo-users] Working directory

by Stephane Ducasse

On Sat, Dec 16, 2017 at 12:01 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 16 December 2017 at 16:02, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi ben >> >> We should think about it. Indeed. >> Now about the names. I'm wondering if they cover well enough the >> situation. >> In fact I would like to have imageDirectory (it exists but not in >> FileSystem) and workingDirectory (I would prefer startupDirectory or >> something like that). > > > startupDirectory sounds like its where the startup scripts are kept, > and common across many Images. > >> For me workingDirectory is totally unclear. > > > Its a fairly well defined concept. Its starts as the shell directory where > you > type the command to run a program. > https://en.wikipedia.org/wiki/Working_directory then we keep it. > We should align with the operating system since file access is ultimately > through system calls like fopen() where relative paths are ultimately affected by > what the operating > system considers to be the working directory (or do we *always* fully > resolve paths > in-Image and only pass absolute paths to fopen() ?) > > Here is a demonstration of working directory on Unix ... > > > $ mkdir temp && cd temp > > $ cat << 'EOF' > testcwd.c > #include <unistd.h> > #include <stdio.h> > char buf[1000]; > int main() > { printf("MYCWD=%s\n", getcwd(buf,1000)); > } > EOF > > $ gcc testcwd.c -o testcwd > > $ ./testcwd > MYCWD=/home/ben/dev/temp > > $ cd .. > > $ temp/testcwd > MYCWD=/home/ben/dev > > > i.e. its the directory where the command was typed in to run the program. > > Since we build on Windows using Cygwin/Ming, its basically the same semantic > for Windows. > and even Win32 has similar function GetCurrentDirectory().... > https://msdn.microsoft.com/en-us/library/windows/desktop/aa364934(v=vs.85).… > > > Now I guess confusion may arise when in Pharo you want to "change the > working directory". > if we only modify some in-Image instance variable? Then a difference of > opinion might arise > between Pharo and operating system calls as to what is the > working-directory" when > relative paths are used. > > Perhaps we should only refer to the operating system's current working > directory. > (Sorry I'm not in a position to dig into that right now) > > > cheers -ben > >> >> >> Now this change is super important for making Pharo >> a good platform for script execution. So let me make it even nicer. >> >> Stef >> >> >> On Fri, Dec 15, 2017 at 10:14 PM, Ben Coman <btc(a)openinworld.com> wrote: >> > >> > >> > On 16 December 2017 at 04:34, Cyril Ferlicot D. >> > <cyril.ferlicot(a)gmail.com> >> > wrote: >> >> >> >> Le 15/12/2017 Ã 21:24, Hilaire a Ã©crit : >> >> > In P3: >> >> > >> >> > FileSystem disk workingDirectory >> >> > =>File @ >> >> > /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared >> >> > >> >> > In P7: >> >> > >> >> > FileSystem disk workingDirectory >> >> > =>File @ /home/hilaire >> >> > >> >> > Is it a bug? >> >> > >> >> >> >> Hi! >> >> >> >> In Pharo 3 >> >> >> >> workingDirectory = imageDirectory. >> >> >> >> In Pharo 7 >> >> >> >> workingDirectory = directory from where Pharo was launched. >> > >> > >> > just double-checking... >> > with equivalent shell commands... >> > $ DIR1 = `pwd` >> > $ $DIR2/pharo $DIR3/Pharo.image >> > >> > Pharo 3 ==> workingDirectory = $DIR3 >> > Pharo 7 ==> workingDirectory = $DIR1 >> > ? >> > >> > I wonder for such a semantic API change it might be good to >> > introduce #workDirectory and deprecate #workingDirectory >> > so the need for user-devs to change their code is more explicit. >> > It might make easier to have an auto-conversion rule #workingDirectory >> > ==> >> > #imageDirectory, >> > and make it harder to shoot yourself in the foot producing >> > cross-platform >> > libraries. >> > >> > cheers -ben >> > >> > >> >> >> >> >> >> Maybe you launched Pharo from the terminal with this command like this >> >> one? >> >> >> >> Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui >> >> Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image >> >> >> >> If you wish to use the old behaviour, you can replace `FileSystem disk >> >> workingDirectory` by `FileLocator imageDirectory asFileReference`. >> >> >> >> This change was done because, not getting the real working directory >> >> make it really hard to script things in Pharo. >> >> >> >> -- >> >> Cyril Ferlicot >> >> https://ferlicot.fr >> >> >> >> http://www.synectique.eu >> >> 2 rue Jacques PrÃ©vert 01, >> >> 59650 Villeneuve d'ascq France >> >> >> > >> >

Dec. 16, 2017