- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PharoMinimal ?

by Pavel Krivanek

Hi Sven, 2017-10-07 16:18 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > What is the story around PharoMinimal and related images ? > > Is there a writeup somewhere with instructions ? > Right now the minimal (Metacello) image based on Pharo 7 is used only as intermediate step in building of the full Pharo and the only real (successful) attempt to use it for something else is PharoLambda (https:// gitlab.com/macta/PharoLambda) In general it can be used for building of own (server) applications. E.g. this way you can install and run Teapot on it: ./pharo Pharo7.0-metacello-32bit-d13eed2.image config http://smalltalkhub .com/mc/zeroflag/Teapot/main ConfigurationOfTeapot --install=stable ./pharo Pharo7.0-metacello-32bit-d13eed2.image eval --no-quit "Teapot on GET: '/welcome' -> 'Hello World'; start." You can load baselines from the Git repositories too but we currently do not have any command line handler for it so you need to do it using "eval" command or *.st flile. Something like this: Metacello new baseline: 'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load To make it more usable we probably should extend it with SUnit and Fuel. If you want to extend it with some packages from vanilla Pharo, you should load them using FileTree from your local Pharo repository clone. Gofer it url: 'filetree:///path-to-my-pharo-repository-clone/pharo/src'; package: 'Multilingual-OtherLanguages'; package: 'Multilingual-TextConverterOtherLanguages'; load. It still needs some care. E.g. some classes from Zinc are not properly initialized (I know about DigitalSignatureAlgorithm MD5NonPrimitive RxMatcher RxParser RxsPredicate SHA1 ZnByteEncoder ZnConstants ZnMimeType ZnNetworkingUtils ZnServer ZnSingleThreadedServer TextConstants TextAction TextStyle). I tried to load Seaside into it today (from the example above) and it failed (some strange error probalby related to Unicode processing). But we will fix it. If you will tell me what exactly you need we can make it work together as in case of PharoLambda. > > I see that we get **FANTASTIC** startup speed with it: > > $ cat /etc/issue > Ubuntu 16.04.3 LTS > > $ ./pharo --version > 5.0-201708271955 Sun Aug 27 20:09:20 UTC 2017 gcc 4.6.3 [Production Spur > VM] > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a > Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: > 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Sun Aug 27 21:55:26 2017 +0200 $ > Plugins: 201708271955 https://github.com/OpenSmallta > lk/opensmalltalk-vm.git $ > Linux testing-gce-ebf45dd8-6a4c-43a5-abd0-e5d8673d05a4 3.13.0-115-generic > #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 > GNU/Linux > plugin path: /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955 > [default: /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955/] > > $ curl get.pharo.org/70-minimal | bash > ... > > $ ./pharo Pharo.image printVersion > [version] 'Pharo7.0' 'Pharo-7.0+alpha.build.172.sha > .d13eed2f80fe19f29fd85ede8c4809d6a6986d4f (32 Bit)' > > $ time ./pharo Pharo.image eval '5 factorial' > 120 > real 0m0.083s > user 0m0.034s > sys 0m0.042s > > That is less than 1/10 of a second on a simple server ! Wow. > > Loading new code in that image seem hard though. > > I see that in http://files.pharo.org/image/70/ there are Pharomonticello > & Pharometacello variants. > > Any pointers on usage/meaning ? > > Monticello is bootstrapped Pharo image with Monticello loaded. This image then loads Metacello and the generated image is the image that we call "minimal". It is minimal in sense minimal for common usage. During Pharo building process we generate: - bootstrapped image - image with Opal that is loaded as binary packages using Hermes - Monticello with only local repositories support - Monticello with network and remote repositories support - Metacello - full Pharo IDE (which is loaded as sequence of several standalone baselines) Cheers, -- Pavel > Thx, > > Sven >

Oct. 8, 2017

Re: [Pharo-dev] Reproducible VM Crash using UFFI

by Esteban Lorenzano

> On 8 Oct 2017, at 10:00, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hi Esteban > > 2017-10-07 5:51 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >> On 7 Oct 2017, at 00:11, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> wrote: >> >> 2017-10-06 2:39 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> >> On 6 Oct 2017, at 05:34, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> wrote: >> >> Hi Nicolas >> >> 2017-10-05 16:04 GMT-03:00 Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com>: >> >> >> >> 2017-10-05 15:42 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> >> >> I tried, now I get an exception "Use ExternalAddress instead!" >> >> I guess the message means Use ExternalAddres in the "out" parameter. >> But replacing byte with ExternalAddress also crashes the VM (crash.dmp >> attached). >> >> >> >> 2017-10-05 10:03 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> On 5 Oct 2017, at 14:55, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >> >> Forgot to comment that Nacl worked in Pharo 5. >> >> >> yes but that was with NB and there are some minimum differences. >> I do not have the library and I lack the time to try more, but seems to >> me that here: >> >> apiCryptoHashSha512Output: outByteArray input: inByteArray inputLength: >> inByteArrayLength >> >> ^ self >> ffiCall: #(long crypto_hash_sha512_ref (byte * >> outByteArray, byte * inByteArray, ulonglong * inByteArrayLength)) >> module: 'libsodiumâ. >> >> >> instead "byte * outByteArrayâ, you want "byte **outByteArrayâ >> >> can you try? >> >> Esteban >> >> >> >> Hmm no, internet reference says: >> >> extern int crypto_hash_sha512_ref(unsigned char *,const unsigned char >> *,unsigned long long); >> >> The error is rather that you pass the address of length rather than the >> length... >> So you pass an erroneous length that may lead to a segfault... >> >> >> Yes, that extra * was the error indeed. >> Thank you Nicolas. >> >> I do not know the VM internals, however I wonder if it is >> understandable to expect a VM crash for a typo like this? >> Maybe it is too difficult to catch in the VM side? >> >> Just asking, not criticizing anyone's work. >> >> >> Of course that is normal. This is C code, any error has the potential to >> crash your program. In C there are no runtime safe guards. >> >> There is a reason why we like/use Pharo. >> >> >> However there are a couple of lightweight libraries which claim to >> provide exceptions for C: >> https://github.com/guillermocalvo/exceptions4c or this one >> https://github.com/psevon/exceptions-and-raii-in-c >> >> I wonder if something like that could be used in UFFI >> >> >> Nothing in C *ever* will save you from accessing bad memory blocks. And yes, >> it will always crash your program. > > Let me see if I get this right. > > If there is nothing to prevent accessing bad memory blocks, assuming > accessing or executing invalid memory, then how the memory debuggers > like mpatrol or valgrind, do their work? Just a rethoric question to > make a point, please keep readingâ¦ they fire a signal and give you an amount of ms to do something before you crash (like writing a stack). thatâs how OS work. > Memory debuggers don't prevent segmentation violation of the debuggee, > but they don't crash either. I know they slow down application, but it > wouldn't be preferable to gracefully recover from crashes during > coding time? My (maybe crazy) idea was while coding sensitive parts > (like using UFFI) one can use a "debugger vm", and use the "normal vm" > when safer. maybe, you could run Pharo inside one of that platforms.Thatâs out of the scope of Pharo itself and I donât know how hard would be, but since Pharo is âjust another appâ, it can be possible. (side note: I used that kind of stuff years ago and programs still crash, just less and producing more information when they do). > > So I think we are talking about different things here. I don't want to > save "bad memory block" errors nor dream about bullet proof VM, but if > we know the bullet then let's use a nice bulletproof vest :) if you want to contribute on that area, I will be very grateful. Sadly I do not have time to work on it right now (nor in the near year(s), if I watch my ever-increasing todo list :( ), and all I can suggest to people is some good practices when programming C interfaces. > > What do you think about having some self-healing feedback loop to > "hide" the crash? like the described in > https://link.springer.com/article/10.1007/s00607-010-0107-y <https://link.springer.com/article/10.1007/s00607-010-0107-y> > > In general, how the VM developers view the resilient systems approach? they don't > Are they too far away to get it right given the current VM complexity? infinite far, since there are no plans at all to tackle this :) > >> those links you point are exception mechanisms, a set of tools to easy the >> catch of programming exceptions. >> But, if you try to read a chunk of memory in, say 0x8000 and the >> data/function that should be there is now garbage, youâre screw. >> >> as Sven pointed, thatâs why we use higher level languages, with GC and all >> that. > > Thank you for the clarifications BTW cheers! Esteban > > HernÃ¡n > >> >> Esteban >> >> >> >> HernÃ¡n >> >> >> >> >> Cheers, >> >> HernÃ¡n >> >> 2017-10-05 3:23 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> H Hernani, >> >> Most probably is a problem in the library and not UFFI, but I could >> not know without a crash report. >> >> Esteban >> >> On 5 Oct 2017, at 06:00, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >> >> Hi, >> >> I ported Nacl (a libsodium wrapper) from the old FFI apicall: format >> to use the UFFI ffiCall:, but there should be something terribly >> wrong >> because is crashing the VM, in both Windows 8.1 and Linux. >> >> How to reproduce in Pharo 6.1 >> >> Metacello new >> smalltalkhubUser: 'tonyg' project: 'Crypto-Nacl'; >> configuration: 'Nacl'; >> version: #development; >> load. >> >> (Nacl hashString: 'The quick brown fox jumps over the lazy dog') hex >> >> This one does deserve a bug entry? >> >> Cheers, >> >> HernÃ¡n

Oct. 8, 2017

Re: [Pharo-dev] Reproducible VM Crash using UFFI

by Stephane Ducasse

Hernan I imagine that valgrind in a "assembler interpreter." It does not blindly execute the next instructions. May be put trap everywhere and I do not think that we can do the same but I'm curious to read the answer about this one. On Sun, Oct 8, 2017 at 10:00 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Esteban > > 2017-10-07 5:51 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> On 7 Oct 2017, at 00:11, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> wrote: >> >> 2017-10-06 2:39 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> >> On 6 Oct 2017, at 05:34, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> wrote: >> >> Hi Nicolas >> >> 2017-10-05 16:04 GMT-03:00 Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com>: >> >> >> >> 2017-10-05 15:42 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> >> >> I tried, now I get an exception "Use ExternalAddress instead!" >> >> I guess the message means Use ExternalAddres in the "out" parameter. >> But replacing byte with ExternalAddress also crashes the VM (crash.dmp >> attached). >> >> >> >> 2017-10-05 10:03 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> On 5 Oct 2017, at 14:55, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >> >> Forgot to comment that Nacl worked in Pharo 5. >> >> >> yes but that was with NB and there are some minimum differences. >> I do not have the library and I lack the time to try more, but seems to >> me that here: >> >> apiCryptoHashSha512Output: outByteArray input: inByteArray inputLength: >> inByteArrayLength >> >> ^ self >> ffiCall: #(long crypto_hash_sha512_ref (byte * >> outByteArray, byte * inByteArray, ulonglong * inByteArrayLength)) >> module: 'libsodiumâ. >> >> >> instead "byte * outByteArrayâ, you want "byte **outByteArrayâ >> >> can you try? >> >> Esteban >> >> >> >> Hmm no, internet reference says: >> >> extern int crypto_hash_sha512_ref(unsigned char *,const unsigned char >> *,unsigned long long); >> >> The error is rather that you pass the address of length rather than the >> length... >> So you pass an erroneous length that may lead to a segfault... >> >> >> Yes, that extra * was the error indeed. >> Thank you Nicolas. >> >> I do not know the VM internals, however I wonder if it is >> understandable to expect a VM crash for a typo like this? >> Maybe it is too difficult to catch in the VM side? >> >> Just asking, not criticizing anyone's work. >> >> >> Of course that is normal. This is C code, any error has the potential to >> crash your program. In C there are no runtime safe guards. >> >> There is a reason why we like/use Pharo. >> >> >> However there are a couple of lightweight libraries which claim to >> provide exceptions for C: >> https://github.com/guillermocalvo/exceptions4c or this one >> https://github.com/psevon/exceptions-and-raii-in-c >> >> I wonder if something like that could be used in UFFI >> >> >> Nothing in C *ever* will save you from accessing bad memory blocks. And yes, >> it will always crash your program. > > Let me see if I get this right. > > If there is nothing to prevent accessing bad memory blocks, assuming > accessing or executing invalid memory, then how the memory debuggers > like mpatrol or valgrind, do their work? Just a rethoric question to > make a point, please keep reading... > > Memory debuggers don't prevent segmentation violation of the debuggee, > but they don't crash either. I know they slow down application, but it > wouldn't be preferable to gracefully recover from crashes during > coding time? My (maybe crazy) idea was while coding sensitive parts > (like using UFFI) one can use a "debugger vm", and use the "normal vm" > when safer. > > So I think we are talking about different things here. I don't want to > save "bad memory block" errors nor dream about bullet proof VM, but if > we know the bullet then let's use a nice bulletproof vest :) > > What do you think about having some self-healing feedback loop to > "hide" the crash? like the described in > https://link.springer.com/article/10.1007/s00607-010-0107-y > > In general, how the VM developers view the resilient systems approach? > Are they too far away to get it right given the current VM complexity? > >> those links you point are exception mechanisms, a set of tools to easy the >> catch of programming exceptions. >> But, if you try to read a chunk of memory in, say 0x8000 and the >> data/function that should be there is now garbage, youâre screw. >> >> as Sven pointed, thatâs why we use higher level languages, with GC and all >> that. > > Thank you for the clarifications BTW > > HernÃ¡n > >> >> Esteban >> >> >> >> HernÃ¡n >> >> >> >> >> Cheers, >> >> HernÃ¡n >> >> 2017-10-05 3:23 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> H Hernani, >> >> Most probably is a problem in the library and not UFFI, but I could >> not know without a crash report. >> >> Esteban >> >> On 5 Oct 2017, at 06:00, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >> >> Hi, >> >> I ported Nacl (a libsodium wrapper) from the old FFI apicall: format >> to use the UFFI ffiCall:, but there should be something terribly >> wrong >> because is crashing the VM, in both Windows 8.1 and Linux. >> >> How to reproduce in Pharo 6.1 >> >> Metacello new >> smalltalkhubUser: 'tonyg' project: 'Crypto-Nacl'; >> configuration: 'Nacl'; >> version: #development; >> load. >> >> (Nacl hashString: 'The quick brown fox jumps over the lazy dog') hex >> >> This one does deserve a bug entry? >> >> Cheers, >> >> HernÃ¡n >> >> >

Oct. 8, 2017

Call for Ruby, Python, Java, Javascript Guide to Pharo

by Stephane Ducasse

Hi Dimitri Preambule: If you want to understand why I react like to the other thread: we are ***FIGHTING*** all day long to build a great system and this is not easy and I do not need to know how great are the other systems. If I want to know I can just drop Pharo and go coding in X. No need to have such discussion on PharoDev where we should be concentrated. Now if you and other want to contribute actively to Pharo here is a simple idea. Create one chapter (I will do the editing) similar to this one (you can also modify this one) to explain to a Pythoner, Rubbyist, Javascripter, the syntax and core libraries of Pharo. https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Java… It was on my todo but I would have to refresh my mind on these languages. Stef

Oct. 8, 2017

Re: [Pharo-dev] Reproducible VM Crash using UFFI

by HernÃ¡n Morales Durand

Hi Esteban 2017-10-07 5:51 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 7 Oct 2017, at 00:11, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > 2017-10-06 2:39 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 6 Oct 2017, at 05:34, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Hi Nicolas > > 2017-10-05 16:04 GMT-03:00 Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com>: > > > > 2017-10-05 15:42 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > > I tried, now I get an exception "Use ExternalAddress instead!" > > I guess the message means Use ExternalAddres in the "out" parameter. > But replacing byte with ExternalAddress also crashes the VM (crash.dmp > attached). > > > > 2017-10-05 10:03 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 5 Oct 2017, at 14:55, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: > > Forgot to comment that Nacl worked in Pharo 5. > > > yes but that was with NB and there are some minimum differences. > I do not have the library and I lack the time to try more, but seems to > me that here: > > apiCryptoHashSha512Output: outByteArray input: inByteArray inputLength: > inByteArrayLength > > ^ self > ffiCall: #(long crypto_hash_sha512_ref (byte * > outByteArray, byte * inByteArray, ulonglong * inByteArrayLength)) > module: 'libsodiumâ. > > > instead "byte * outByteArrayâ, you want "byte **outByteArrayâ > > can you try? > > Esteban > > > > Hmm no, internet reference says: > > extern int crypto_hash_sha512_ref(unsigned char *,const unsigned char > *,unsigned long long); > > The error is rather that you pass the address of length rather than the > length... > So you pass an erroneous length that may lead to a segfault... > > > Yes, that extra * was the error indeed. > Thank you Nicolas. > > I do not know the VM internals, however I wonder if it is > understandable to expect a VM crash for a typo like this? > Maybe it is too difficult to catch in the VM side? > > Just asking, not criticizing anyone's work. > > > Of course that is normal. This is C code, any error has the potential to > crash your program. In C there are no runtime safe guards. > > There is a reason why we like/use Pharo. > > > However there are a couple of lightweight libraries which claim to > provide exceptions for C: > https://github.com/guillermocalvo/exceptions4c or this one > https://github.com/psevon/exceptions-and-raii-in-c > > I wonder if something like that could be used in UFFI > > > Nothing in C *ever* will save you from accessing bad memory blocks. And yes, > it will always crash your program. Let me see if I get this right. If there is nothing to prevent accessing bad memory blocks, assuming accessing or executing invalid memory, then how the memory debuggers like mpatrol or valgrind, do their work? Just a rethoric question to make a point, please keep reading... Memory debuggers don't prevent segmentation violation of the debuggee, but they don't crash either. I know they slow down application, but it wouldn't be preferable to gracefully recover from crashes during coding time? My (maybe crazy) idea was while coding sensitive parts (like using UFFI) one can use a "debugger vm", and use the "normal vm" when safer. So I think we are talking about different things here. I don't want to save "bad memory block" errors nor dream about bullet proof VM, but if we know the bullet then let's use a nice bulletproof vest :) What do you think about having some self-healing feedback loop to "hide" the crash? like the described in https://link.springer.com/article/10.1007/s00607-010-0107-y In general, how the VM developers view the resilient systems approach? Are they too far away to get it right given the current VM complexity? > those links you point are exception mechanisms, a set of tools to easy the > catch of programming exceptions. > But, if you try to read a chunk of memory in, say 0x8000 and the > data/function that should be there is now garbage, youâre screw. > > as Sven pointed, thatâs why we use higher level languages, with GC and all > that. Thank you for the clarifications BTW HernÃ¡n > > Esteban > > > > HernÃ¡n > > > > > Cheers, > > HernÃ¡n > > 2017-10-05 3:23 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > H Hernani, > > Most probably is a problem in the library and not UFFI, but I could > not know without a crash report. > > Esteban > > On 5 Oct 2017, at 06:00, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: > > Hi, > > I ported Nacl (a libsodium wrapper) from the old FFI apicall: format > to use the UFFI ffiCall:, but there should be something terribly > wrong > because is crashing the VM, in both Windows 8.1 and Linux. > > How to reproduce in Pharo 6.1 > > Metacello new > smalltalkhubUser: 'tonyg' project: 'Crypto-Nacl'; > configuration: 'Nacl'; > version: #development; > load. > > (Nacl hashString: 'The quick brown fox jumps over the lazy dog') hex > > This one does deserve a bug entry? > > Cheers, > > HernÃ¡n > >

Oct. 8, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Tim Mackinnon

I see the answer is due to STON - fine I'll live with it. I think we missed a chance to superficially look like more conventional languages on the web in GitHub but that ship had sailed and maybe it's not such a bad thing. I'll happily take just been able to efficiently use GitHub asap any day. So please keep rolling forward. Tim Sent from my iPhone > On 7 Oct 2017, at 09:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Tim > > we talk about this format of methods year ago and we will like it and > we will not discuss it anymore. > For the record a method is a named block so it fits and we do not have > to have {} for method delimiters. > > Stef > >> On Fri, Oct 6, 2017 at 11:34 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> Gosh - It actually work quite well to be able to easily browse code online >> in a more traditional format of seeing an entire class. Hopefully this leads >> to us being able to share solutions to common language agnostic problems. >> >> One small observation - I quickly grokâd the use of class { â¦. } (with the >> curly braces) - but given that smalltalk methods often have lots of [ ] >> (square braces in them), I was a bit surprised to see that method >> declarations in tonal donât use { â¦ } (curly braces) to denote them, but >> instead use [ ] - which feels slightly strange given the class declaration >> above has. {}. >> >> Was it easier to parse this way, or is there some subtlety I missed? I would >> have been tempted to use {} for classes and methods and [] for the >> protocols as this more closely matches what other languages do - and it >> might actually make it more easily readable for other programmers. Given we >> have to learn this new format anyway - Iâd be prepared to give a nod to what >> others doâ¦ >> >> Possibly this observation comes to late - and maybe there is compelling >> reason to go the route we have gone - but maybe its worth a quick double >> check as its an exciting development. >> >> Tim >> >> On 6 Oct 2017, at 18:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi all, >> >> I released Iceberg version 0.6. It includes a lot of small tweaks and fixes, >> but the most important inclusion is tonel file format which aims to replace >> file tree. >> >> What is Tonel? (https://github.com/pharo-vcs/tonel) >> Tonel is a file-per-class file format for monticello repositories. Itâs >> purpose is to reduce the amount of files touched each operation, make the IO >> faster an compact the repositories database. >> It has also as an objective to offer an âeasy-to-readâ format, so people >> wanting to understand a chunk of code will recognise it easily. >> For testing, I migrated several of my projects to Tonel and Iâve been using >> it, you can see some as examples: >> >> https://github.com/estebanlm/MUDClient >> https://github.com/estebanlm/pharo-tonel (this was just an example and it >> has some minimal errors already fixed) >> >> We plan to migrate Pharo development to tonel to address some problems we >> have: >> >> - since it has to read/write a lot of files, IO operations are slow >> - and even much more slow in Windows >> - Windows also has a problem with longpaths. >> >> Iceberg 0.6 will be integrated to Pharo7 soon :) >> To update Pharo 6.1, there are instructions in the readme: >> https://github.com/pharo-vcs/iceberg/blob/master/README.md >> now, if you wan to migrate your projects to Tonel (from FileTree), here is a >> script you can use: >> https://github.com/pharo-vcs/tonel/blob/master/MigrateFromFileTree.md >> >> btw, tonel is independent of Iceberg and can be used with plain Monticello >> (but it is a metadaless format, history will reside on git, not on >> monticello). >> >> cheers, >> Esteban >> >> >

Oct. 7, 2017

Re: [Pharo-dev] Swimming with the fish imagery

by Stephane Ducasse

Ben you should have a look super fast at the mooc because some lectures are nice pearls. Anyway: I was talking about http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W1/C019SD-W1-S2-v2.mp4 looks for the aquariums :) Stef On Sat, Oct 7, 2017 at 1:38 PM, Ben Coman <btc(a)openinworld.com> wrote: > I haven't. I just went looking for it through all the video links here... > http://files.pharo.org/mooc/ > and couldn't recognise which you refer to. Do you have a link? > > cheers -ben > > On Sat, Oct 7, 2017 at 4:23 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Did you watch the What is Pharo videos of the mooc :) >> >> On Sat, Oct 7, 2017 at 3:16 AM, Ben Coman <btc(a)openinworld.com> wrote: >> > >> > "Swimming with the fish" is a catchy phrase that I like which seems to >> > encompass the strength of Pharo's tight development feedback loop that >> > comes >> > from operating in a world of live objects. I had some imagery floating >> > through my head on this I thought worth sharing. Only time for a quick >> > dump, >> > but I hope you can piece it together... >> > >> > >> > In the style of one of those fast paced cartoon product videos... >> > >> > Scene 1: >> > "The development process we all know..." >> > A neutral background with directed arcs in circle >> > "Debug-->Edit-->Compile-->Execute-->" >> > >> > >> > Scene 2: >> > "In most languages... debugging..." >> > Zoom in on Aquarium 1 to show a developer standing outside aquarium >> > window... >> > https://tinyurl.com/PharoSwimWithTheFish-Outside >> > >> > reaching in through quarantine-box-like-gloxes to use telescopic tools >> > to >> > pick up and examine fish at a distance... >> > https://tinyurl.com/PharoSwimWithTheFish-OtherTool >> > >> > until the lightbulb moment... >> > https://tinyurl.com/PharoSwimWithTheFish-Lightbulb >> > >> > >> > Scene 3: >> > "In most languages... editing...." >> > Developer zooms out away from aquarium. It folds up into a tiny box and >> > drops in a bin. >> > Developer zooms in on an architectural drafting table with many drawings >> > with many different but simple flow diagrams on each. Quickly make >> > required >> > edit to flow diagrams. >> > https://tinyurl.com/PharoSwimWithTheFish-OtherEdit >> > >> > >> > Scene 4: >> > "In most languages... compiling..." >> > Drawings pass through a photocopier into a box that is transferred to >> > site >> > supervisor. >> > At an empty flat construction site, supervisor opens box pulling out >> > drawings to review them. >> > Trucks and machines arrive and start building the aquarium at his >> > direction... >> > Two buildings clash when they overlap the same space (compile error). >> > Return >> > to Scene 3 to fix design then rerun Scene 4 through to completion. >> > >> > >> > Scene 5: >> > " In most languages... execution..." >> > Water trucks arrive and pour water into the pool, then more trucks >> > arrive >> > adding the fish. >> > (i.e. initialization and getting to the point of the program you want >> > check >> > again) >> > >> > >> > Scene 6: >> > "In most languages... debugging..." >> > Complete the loop by starting scene 3 again. >> > >> > >> > Scene 7: >> > "In Pharo.... debugging..." >> > Zoom out, over and into Aquarium 2 where a developer is swimming inside >> > the >> > pool... >> > https://tinyurl.com/PharoSwimWithTheFish-Inside >> > >> > http://blog.atlantisthepalm.com/wp-content/uploads/2017/05/different-in-wat… >> > >> > Developer grabs a fish, shifts it aside, lets it go to swim some more, >> > grabs >> > it again, holds it up close to look a small detail. Out of nothing >> > creates >> > a new fish to interact with the first fish. >> > Out of nothing creates some clay and then moulds a new scope-like tool >> > from >> > it to look at the fish differently. >> > >> > Lightbulb moment... >> > https://tinyurl.com/PharoSwimWithTheFish-Lightbulb >> > >> > "In Pharo.... editing..." >> > Developer peers into brain of fish seeing many neurons, picks one out >> > which >> > shows as simple flow diagram, makes a change to it. >> > >> > "In Pharo.... compiling..." >> > Laser beam quickly scans the simple flow diagram and packs neuron back >> > into >> > the fish. >> > >> > "In Pharo.... execution..." >> > Fish swims off. >> > >> > "In Pharo.... debugging..." >> > Developer grabs another fish... >> > >> > >> > Scene 8: >> > Zoom out to show both aquariums. >> > In Aquarium 1, repetitively run through Scenes 2 through 6 >> > In Aquarium 2, repetitively run through Scene 7. >> > Play at 10x original speed. >> > >> > Fade in a "Debug-->Edit-->Compile-->Run-->" over each aquarium, showing >> > synced state transitions. >> > >> > Fade in "Come swim with the fish with Pharo" >> > Fade in "It will change the way you think about programming" >> > >> > >> > cheers -ben >> >

Oct. 7, 2017

Re: [Pharo-dev] slots & first class relations

by Stephane Ducasse

I would love that someone work on a Pharo modeling library: Pharo + relationships. Stef On Sat, Oct 7, 2017 at 2:45 PM, Ben Coman <btc(a)openinworld.com> wrote: > thx for the tip. > cheers -ben > > > On Sat, Oct 7, 2017 at 8:24 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Take a look at the "Slot" package in Pharo. >> There's "Examples" and "Examples-Associations" (first class relations) >> tags. >> >> Peter >> >> On Sat, Oct 7, 2017 at 1:32 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> Just wondering what was the status of Slots regarding "first class >>> relations" described in "Flexible Object Layouts" - and availability of >>> examples/tutorials. >>> https://core.ac.uk/download/pdf/51216612.pdf >>> >>> cheers -ben >> >> >

Oct. 7, 2017

Re: [Pharo-dev] PharoMinimal ?

by Stephane Ducasse

I will let guille and pavel reply because they know. Sven guille and/or Pavel sent a mail a while ago explaining all the different stages. What I want is that we continue shrinking the core and get a modular system. We are getting there for real. ;) Stef On Sat, Oct 7, 2017 at 4:18 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > What is the story around PharoMinimal and related images ? > > Is there a writeup somewhere with instructions ? > > I see that we get **FANTASTIC** startup speed with it: > > $ cat /etc/issue > Ubuntu 16.04.3 LTS > > $ ./pharo --version > 5.0-201708271955 Sun Aug 27 20:09:20 UTC 2017 gcc 4.6.3 [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ > Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Linux testing-gce-ebf45dd8-6a4c-43a5-abd0-e5d8673d05a4 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux > plugin path: /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955 [default: /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955/] > > $ curl get.pharo.org/70-minimal | bash > ... > > $ ./pharo Pharo.image printVersion > [version] 'Pharo7.0' 'Pharo-7.0+alpha.build.172.sha.d13eed2f80fe19f29fd85ede8c4809d6a6986d4f (32 Bit)' > > $ time ./pharo Pharo.image eval '5 factorial' > 120 > real 0m0.083s > user 0m0.034s > sys 0m0.042s > > That is less than 1/10 of a second on a simple server ! Wow. > > Loading new code in that image seem hard though. > > I see that in http://files.pharo.org/image/70/ there are Pharomonticello & Pharometacello variants. > > Any pointers on usage/meaning ? > > Thx, > > Sven

Oct. 7, 2017

PharoMinimal ?

by Sven Van Caekenberghe

Hi, What is the story around PharoMinimal and related images ? Is there a writeup somewhere with instructions ? I see that we get **FANTASTIC** startup speed with it: $ cat /etc/issue Ubuntu 16.04.3 LTS $ ./pharo --version 5.0-201708271955 Sun Aug 27 20:09:20 UTC 2017 gcc 4.6.3 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-ebf45dd8-6a4c-43a5-abd0-e5d8673d05a4 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux plugin path: /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955 [default: /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955/] $ curl get.pharo.org/70-minimal | bash ... $ ./pharo Pharo.image printVersion [version] 'Pharo7.0' 'Pharo-7.0+alpha.build.172.sha.d13eed2f80fe19f29fd85ede8c4809d6a6986d4f (32 Bit)' $ time ./pharo Pharo.image eval '5 factorial' 120 real 0m0.083s user 0m0.034s sys 0m0.042s That is less than 1/10 of a second on a simple server ! Wow. Loading new code in that image seem hard though. I see that in http://files.pharo.org/image/70/ there are Pharomonticello & Pharometacello variants. Any pointers on usage/meaning ? Thx, Sven

Oct. 7, 2017