January 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 9 Jan 2018, at 09:30, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 9 Jan 2018, at 08:22, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Sean, >> >> On 9 January 2018 at 05:00, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> EstebanLM wrote >>>> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. >>> >>> I added my local pharo fork clone and got the red Morphic square of death in >>> Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: >>> Object not found - no match for id >>> (b98b37b641381ac07906c020bbc8b4675ed4027b)" >> >> I'm getting the LGit_GIT_ENOTFOUND when I load a clean image. The id >> appears to be the commit id from a different repository (in my case it >> happens to be the repository directly under the one with the error). > > Mmm. I think this is because your local clone is outdated. > It should be fixed with a fetch. a fetch from pharo-project, I mean :) > > Esteban > >> >> I haven't looked in to this further yet, but the short term workaround >> is to reload all the packages in the repository with the error. >> >> Cheers, >> Alistair >> >> >> >>> Image >>> ----- >>> Pharo7.0alpha >>> Build information: >>> Pharo-7.0+alpha.build.414.sha.53eba9479e615417df06b782fc663e9a9407a404 (32 >>> Bit) >>> Unnamed >>> >>> Virtual Machine >>> --------------- >>> ~/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS/Pharo >>> 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 $ >>> >>> Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple >>> LLVM 6.1.0 (clang-602.0.53) >>> VMMaker versionString 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 $ >>> 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 >>> >>> Operating System/Hardware >>> ------------------------- >>> Mac OS 1013.2 intel >>> >>> >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 9, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 9 Jan 2018, at 08:22, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sean, > > On 9 January 2018 at 05:00, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> EstebanLM wrote >>> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. >> >> I added my local pharo fork clone and got the red Morphic square of death in >> Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: >> Object not found - no match for id >> (b98b37b641381ac07906c020bbc8b4675ed4027b)" > > I'm getting the LGit_GIT_ENOTFOUND when I load a clean image. The id > appears to be the commit id from a different repository (in my case it > happens to be the repository directly under the one with the error). Mmm. I think this is because your local clone is outdated. It should be fixed with a fetch. Esteban > > I haven't looked in to this further yet, but the short term workaround > is to reload all the packages in the repository with the error. > > Cheers, > Alistair > > > >> Image >> ----- >> Pharo7.0alpha >> Build information: >> Pharo-7.0+alpha.build.414.sha.53eba9479e615417df06b782fc663e9a9407a404 (32 >> Bit) >> Unnamed >> >> Virtual Machine >> --------------- >> ~/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS/Pharo >> 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 $ >> >> Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple >> LLVM 6.1.0 (clang-602.0.53) >> VMMaker versionString 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 $ >> 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 >> >> Operating System/Hardware >> ------------------------- >> Mac OS 1013.2 intel >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >

Jan. 9, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Alistair Grant

Hi Sean, On 9 January 2018 at 05:00, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > EstebanLM wrote >> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. > > I added my local pharo fork clone and got the red Morphic square of death in > Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: > Object not found - no match for id > (b98b37b641381ac07906c020bbc8b4675ed4027b)" I'm getting the LGit_GIT_ENOTFOUND when I load a clean image. The id appears to be the commit id from a different repository (in my case it happens to be the repository directly under the one with the error). I haven't looked in to this further yet, but the short term workaround is to reload all the packages in the repository with the error. Cheers, Alistair > Image > ----- > Pharo7.0alpha > Build information: > Pharo-7.0+alpha.build.414.sha.53eba9479e615417df06b782fc663e9a9407a404 (32 > Bit) > Unnamed > > Virtual Machine > --------------- > ~/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS/Pharo > 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 $ > > Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple > LLVM 6.1.0 (clang-602.0.53) > VMMaker versionString 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 $ > 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 > > Operating System/Hardware > ------------------------- > Mac OS 1013.2 intel > > > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Jan. 9, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Sean P. DeNigris

EstebanLM wrote > PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. I added my local pharo fork clone and got the red Morphic square of death in Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: Object not found - no match for id (b98b37b641381ac07906c020bbc8b4675ed4027b)" Image ----- Pharo7.0alpha Build information: Pharo-7.0+alpha.build.414.sha.53eba9479e615417df06b782fc663e9a9407a404 (32 Bit) Unnamed Virtual Machine --------------- ~/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS/Pharo 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 $ Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) VMMaker versionString 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 $ 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 Operating System/Hardware ------------------------- Mac OS 1013.2 intel ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 9, 2018

Re: [Pharo-dev] identifying source of particular VM

by Ben Coman

TLDR; Both my opensmalltalk and pharo git problems were essentially trying to work with a kind of "stale" repo. Taking fresh fork/clone of each seems to have fixed everything. On 9 January 2018 at 03:43, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Ben, > > it is the "short" commit hash from the official OpenSmalltalk github repo > so you can reproduce the "VM" build easily: > > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/276a5ff Thanks. That confirmed understanding to allow me to attack the real problem. Part of my problem was that I presumed that our Pharo VMs were being built from the tip, so... $ git fetch -all $ git show 276a5ff $ git log origin/Cog | grep 276a5ff $ git checkout 276a5ff would show something, but they were not. Turns out something was broken. Trying to look at branches of the remote origin... $ get fetch -all $ git branch -rv was only showing two branches local "Cog" and "origin/Cog". I can't tell why, since its been a while since I've played in this git repo folder. Perhaps previously I experimented with --single-branch. Now after blowing away the folder and recloning "git branch -rv" now shows two dozen branch, and $ git show 276a5ff $ git checkout 276a5ff now work as expected. Later I found something related https://stackoverflow.com/ questions/17714159/how-do-i-undo-a-single-branch-clone Interestingly $ git log origin/Cog | grep 276a5ff still doesn't show anything since it hasn't been integrated with the Cog branch (see attached pic). > From Pharo 7 onwards now also the "image" is completely bootstrapped - you > also have a commit hash > for the image to reproduce the image build/commit: > > https://github.com/pharo-project/pharo/commits/53eba94 > > Some details for the image hash can be found here: > http://forum.world.st/SystemVersion-cleanup-or-the-return- > of-the-explicit-build-number-in-latest-Pharo-7-td4977073.html > > We meanwhile also restored the image build number, so you can load the > image with PharoLauncher with the > build number again. The latest is 70414 as of today which mean Pharo 7, > Build 414. > Its good to have both simple human parsable build number and hash reference. My thanks to those that fixed that and PharoLauncher. Its become usable for Pharo 7. > You can go to "http://wiki.astares.com/pharo/30" and click on "alpha" to > visit the Pharo CI for the build number. > > Side note: From some of you last posts I see you still struggling with git > or Iceberg issues. I think I finally figured this out. It seems I was confounding things from having an old "pharo" repo on github cloned before there was a "development" branch. So after Iceberg cloned "pharo" its default branch was "master" rather than "development" and (in hindsight) of course would not synchronise with the Pharo mainline "development" branch per the presented contribution workflow. After blowing away my "pharo" fork on github and reforking, everything went smoothly. Also, some terms like "Synchronise" are not standard git terms, so trying to understand their semantics in the face of that confounding behaviour didn't help my confidence at the time. cheers -ben > Had similar trouble in the beginning when > Pharo process was switched to git and Iceberg was > introduced. Because I tried always to compare with/tried to apply what > I knew from VisualSourceSafe, ClearCase, SVN, Envy, > Monticello, ... and many other VCS systems that I used before. > > So I bought the "Pro Git" from Apress book which helped me > a lot understanding "git" (also some internals) first. > I can really recommend to study it. It will safe you a lot > of pain. > > You can find it on the web too: > https://git-scm.com/book/en/v1 (first version) > https://git-scm.com/book/en/v2 (new version) > > Bye > T. > > > > Gesendet: Montag, 08. Januar 2018 um 19:45 Uhr > Von: "Eliot Miranda" <eliot.miranda(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] identifying source of particular VM > > Hi Ben, > > I think that the hash is indeed that if a commit. And I thought > someone had written a script to find the commit from the hash. > Alternatively you could look at the various system attributes the Squeak vm > uses to identify itself. I *think* the Pharo vm has the same info baked > in. In particular there should be the date of the commit. > > _,,,^..^,,,_ (phone) > On Jan 8, 2018, at 6:36 AM, Ben Coman <btc@openinworld.com[mailto:bt > c(a)openinworld.com]> wrote: > > > This filename of the VM download url... http://files.pharo.org/ > vm/pharo-spur64/linux/pharo-linux-x86_64threaded-20171221145 > 0-276a5ff.zip[http://files.pharo.org/vm/pharo-spur64/ > linux/pharo-linux-x86_64threaded-201712211450-276a5ff.zip] > > includes a hash "276a5ff" that I presumed identified the opensmalltalk-vm > commit from which this VM was built. i.e. so I could check that out if I > wanted to compile a debug version of that VM. > > However... > $ git checkout 276a5ff > says... error: pathspec '276a5ff' did not match any file(s) known to git. > > so what exactly is that hash 276a5ff in the filename? > > cheers -ben > >

Jan. 9, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2017-01-01

by Esteban Lorenzano

> On 8 Jan 2018, at 23:09, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2018-01-08 22:42 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: > Hi Pavel > > I was thinking that it would be nice to have a simple DB build in > Pharo (I thought that CDB could do the job) to manage source. > Because I like the idea that when the system crashes I only lose at > max the method I'm editing. cdb cannot because it means âconstant databaseâ : once created, cannot be modified and we will need to install sources there. tyrantdb was just a PoCâ¦ it was cool, but just thatâ¦ lot of work to make it a real replacement (and also, there is the FFI dependence problem). > Esteban did once a try to connect a tokyo tyrant db now I would prefer > to avoid to have FFI in the middle. > To me we should **********stabilise*********** pharo for real. > > There is a lot of things we want to change in the system. Just integration of Calypso and removal of the old FileStream users could cause a lot of issues. So we should really think what to do with Pharo 7 release. Of course I would like to see a lot of the cool new features in Pharo 7 but we will probably need to decide between some of them and stability. Compressed in-memory sources are of course not really important. yes. I still didnât do the âfreezeâ call because there are tons of things that still need a lot of work. and we still need to introduce SISTA (preview). but I would not introduce anything else right now, and that includes Calypso, image-based-sources (or DB sources) and any of the cool stuff we have in the pipelineâ¦ just because if we introduce it we will release super later. Esteban > > -- Pavel > > > > Stef > > On Mon, Jan 8, 2018 at 4:50 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > > > > > > 2018-01-08 16:27 GMT+01:00 Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>>: > >> > >> > >> > >> On Mon, Jan 8, 2018 at 6:30 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> > >> wrote: > >>> > >>> In memory sources file > >>> - I slightly improved the PR for integration of the sources file inside > >>> the object memory. Now it will be possible to extract them back to the disk > >>> from the menu so everything can work as before. I'm not sure if it will be > >>> integrated into Pharo 7 or we will wait for Pharo 8 but it seems to be > >>> prepared. > >>> > >>> File API and caching > >>> - because the in-memory sources file do not use deprecated > >>> MultiByteFileStream, I played with the new file API and discovered that > >>> ZnCharacterReadStream on File is about 10 times slower than the old > >>> MultiByteFileStream. That's because ZnCharacterReadStream does not use any > >>> cache. For better speed the ZnBufferedReadStream needs to be used like this: > >>> > >>> readStream := File openForReadFileNamed: 'file.txt'. > >>> zn := ZnCharacterReadStream on: readStream encoding: #UTF8. > >>> buffered := ZnBufferedReadStream on: zn. > >>> [ buffered atEnd ] whileFalse: [ buffered next: 20000 ]. > >>> > >>> However the ZnBufferedReadStream is by design only a linear stream and > >>> the position cannot be changed and thus it cannot be used for *.sources > >>> files etc. We will need to prepare a positionable alternative. > >>> > >> > >>> > >>> Ring 2 integration > >>> - I was working on replacing of the old Ring with the new > >>> reimplementation. The old Ring is used on many sensitive places in the > >>> system. Mainly in tools however it is used by Monticello and Epicea too so > >>> to try to remove it is like to cut a branch below yourself on an undermined > >>> tree. The approach of the old and new Ring is in many senses very different > >>> and the full compatibility will not be supported. I partly provide > >>> compatibility API, partly adopt the code directly. > >> > >> > >> Great news. I didn't look at Ring 2 code recently but I say your esug talk > >> and I imagine it will fit well for the change model and UI tool. > >> > >> What may need attention is serialization to text file. Right now, the Ring > >> 1 object returned by asRingDefinition (+ some tweaks) is serialized and > >> materialized via STON into the .ombu files. With Ring 2 serialized with > >> STON, the file format will be different and in consequence the new epicea > >> won't be able to open a .ombu file generated in Ring 1. Not sure if Pharo > >> community find this acceptable. IMO it is. > >> - If not-acceptable, there could be some workaround. > >> - If acceptable, that's the easiest path, and also it could be a good > >> opportunity to improve the file format: It could be more compact and even > >> have a better extension such as .epicea or something that comunicates that > >> tthose files have code changes or sessions. > > > > > > I think that the change of the format is not a a practical issue because > > probably no-one will need to read the old Ombu files from a different Pharo > > version. > > But a change of the format will be handy because every Ring2 model is a > > standalone environment and Ombu thus saves all information that it includes. > > So a simple method change creates a record with almost 400 lines. It must be > > of course much slower too. > > > > -- Pavel > > > >> > >> cheers, > >> MartÃn > >> > >>> > >>> - The real system and the model is mixed many times in the users of the > >>> old Ring. For example a model for a method is created but then when the > >>> package of the method is asked, it is already a real package, not its model. > >>> Such places need to be cleaned. > >>> - I already have an image that has no old Ring code at all but because of > >>> some memory leaks caused by the mixtures of the models and real system I was > >>> not able to bootstrap it successfully. More work is needed. > >>> - I discovered that the image has a serious memory leak caused by > >>> Iceberg/GT and Announcers but I still need to find more information about > >>> it. > >>> > >>> Smalltalk archeology > >>> - during the free days on the beginning of the year I looked at > >>> Smalltalk-78. I extracted the data from Lively Kernel so the original image > >>> can read from external files, not only the recent updated ones. > >>> - Then I looked at SqueakJS again and tried to reproduce Craig's > >>> experiments with Pharo on it. Generally it is about 100 times slower than > >>> native Pharo which makes it hard to use for real-life tasks. However it > >>> would be pity to do not provide at least basic attention to it because in > >>> some cases it may be really useful. > >>> > >>> Cheers, > >>> -- Pavel > >>> > >>> > >> > > > >

Jan. 8, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2017-01-01

by Pavel Krivanek

2018-01-08 22:42 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi Pavel > > I was thinking that it would be nice to have a simple DB build in > Pharo (I thought that CDB could do the job) to manage source. > Because I like the idea that when the system crashes I only lose at > max the method I'm editing. > Esteban did once a try to connect a tokyo tyrant db now I would prefer > to avoid to have FFI in the middle. > To me we should **********stabilise*********** pharo for real. > There is a lot of things we want to change in the system. Just integration of Calypso and removal of the old FileStream users could cause a lot of issues. So we should really think what to do with Pharo 7 release. Of course I would like to see a lot of the cool new features in Pharo 7 but we will probably need to decide between some of them and stability. Compressed in-memory sources are of course not really important. -- Pavel > Stef > > On Mon, Jan 8, 2018 at 4:50 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > > > 2018-01-08 16:27 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > >> > >> > >> > >> On Mon, Jan 8, 2018 at 6:30 AM, Pavel Krivanek < > pavel.krivanek(a)gmail.com> > >> wrote: > >>> > >>> In memory sources file > >>> - I slightly improved the PR for integration of the sources file inside > >>> the object memory. Now it will be possible to extract them back to the > disk > >>> from the menu so everything can work as before. I'm not sure if it > will be > >>> integrated into Pharo 7 or we will wait for Pharo 8 but it seems to be > >>> prepared. > >>> > >>> File API and caching > >>> - because the in-memory sources file do not use deprecated > >>> MultiByteFileStream, I played with the new file API and discovered that > >>> ZnCharacterReadStream on File is about 10 times slower than the old > >>> MultiByteFileStream. That's because ZnCharacterReadStream does not use > any > >>> cache. For better speed the ZnBufferedReadStream needs to be used like > this: > >>> > >>> readStream := File openForReadFileNamed: 'file.txt'. > >>> zn := ZnCharacterReadStream on: readStream encoding: #UTF8. > >>> buffered := ZnBufferedReadStream on: zn. > >>> [ buffered atEnd ] whileFalse: [ buffered next: 20000 ]. > >>> > >>> However the ZnBufferedReadStream is by design only a linear stream and > >>> the position cannot be changed and thus it cannot be used for *.sources > >>> files etc. We will need to prepare a positionable alternative. > >>> > >> > >>> > >>> Ring 2 integration > >>> - I was working on replacing of the old Ring with the new > >>> reimplementation. The old Ring is used on many sensitive places in the > >>> system. Mainly in tools however it is used by Monticello and Epicea > too so > >>> to try to remove it is like to cut a branch below yourself on an > undermined > >>> tree. The approach of the old and new Ring is in many senses very > different > >>> and the full compatibility will not be supported. I partly provide > >>> compatibility API, partly adopt the code directly. > >> > >> > >> Great news. I didn't look at Ring 2 code recently but I say your esug > talk > >> and I imagine it will fit well for the change model and UI tool. > >> > >> What may need attention is serialization to text file. Right now, the > Ring > >> 1 object returned by asRingDefinition (+ some tweaks) is serialized and > >> materialized via STON into the .ombu files. With Ring 2 serialized with > >> STON, the file format will be different and in consequence the new > epicea > >> won't be able to open a .ombu file generated in Ring 1. Not sure if > Pharo > >> community find this acceptable. IMO it is. > >> - If not-acceptable, there could be some workaround. > >> - If acceptable, that's the easiest path, and also it could be a good > >> opportunity to improve the file format: It could be more compact and > even > >> have a better extension such as .epicea or something that comunicates > that > >> tthose files have code changes or sessions. > > > > > > I think that the change of the format is not a a practical issue because > > probably no-one will need to read the old Ombu files from a different > Pharo > > version. > > But a change of the format will be handy because every Ring2 model is a > > standalone environment and Ombu thus saves all information that it > includes. > > So a simple method change creates a record with almost 400 lines. It > must be > > of course much slower too. > > > > -- Pavel > > > >> > >> cheers, > >> MartÃn > >> > >>> > >>> - The real system and the model is mixed many times in the users of the > >>> old Ring. For example a model for a method is created but then when the > >>> package of the method is asked, it is already a real package, not its > model. > >>> Such places need to be cleaned. > >>> - I already have an image that has no old Ring code at all but because > of > >>> some memory leaks caused by the mixtures of the models and real system > I was > >>> not able to bootstrap it successfully. More work is needed. > >>> - I discovered that the image has a serious memory leak caused by > >>> Iceberg/GT and Announcers but I still need to find more information > about > >>> it. > >>> > >>> Smalltalk archeology > >>> - during the free days on the beginning of the year I looked at > >>> Smalltalk-78. I extracted the data from Lively Kernel so the original > image > >>> can read from external files, not only the recent updated ones. > >>> - Then I looked at SqueakJS again and tried to reproduce Craig's > >>> experiments with Pharo on it. Generally it is about 100 times slower > than > >>> native Pharo which makes it hard to use for real-life tasks. However it > >>> would be pity to do not provide at least basic attention to it because > in > >>> some cases it may be really useful. > >>> > >>> Cheers, > >>> -- Pavel > >>> > >>> > >> > > > >

Jan. 8, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2017-01-01

by Stephane Ducasse

Hi Pavel I was thinking that it would be nice to have a simple DB build in Pharo (I thought that CDB could do the job) to manage source. Because I like the idea that when the system crashes I only lose at max the method I'm editing. Esteban did once a try to connect a tokyo tyrant db now I would prefer to avoid to have FFI in the middle. To me we should **********stabilise*********** pharo for real. Stef On Mon, Jan 8, 2018 at 4:50 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2018-01-08 16:27 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: >> >> >> >> On Mon, Jan 8, 2018 at 6:30 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >>> >>> In memory sources file >>> - I slightly improved the PR for integration of the sources file inside >>> the object memory. Now it will be possible to extract them back to the disk >>> from the menu so everything can work as before. I'm not sure if it will be >>> integrated into Pharo 7 or we will wait for Pharo 8 but it seems to be >>> prepared. >>> >>> File API and caching >>> - because the in-memory sources file do not use deprecated >>> MultiByteFileStream, I played with the new file API and discovered that >>> ZnCharacterReadStream on File is about 10 times slower than the old >>> MultiByteFileStream. That's because ZnCharacterReadStream does not use any >>> cache. For better speed the ZnBufferedReadStream needs to be used like this: >>> >>> readStream := File openForReadFileNamed: 'file.txt'. >>> zn := ZnCharacterReadStream on: readStream encoding: #UTF8. >>> buffered := ZnBufferedReadStream on: zn. >>> [ buffered atEnd ] whileFalse: [ buffered next: 20000 ]. >>> >>> However the ZnBufferedReadStream is by design only a linear stream and >>> the position cannot be changed and thus it cannot be used for *.sources >>> files etc. We will need to prepare a positionable alternative. >>> >> >>> >>> Ring 2 integration >>> - I was working on replacing of the old Ring with the new >>> reimplementation. The old Ring is used on many sensitive places in the >>> system. Mainly in tools however it is used by Monticello and Epicea too so >>> to try to remove it is like to cut a branch below yourself on an undermined >>> tree. The approach of the old and new Ring is in many senses very different >>> and the full compatibility will not be supported. I partly provide >>> compatibility API, partly adopt the code directly. >> >> >> Great news. I didn't look at Ring 2 code recently but I say your esug talk >> and I imagine it will fit well for the change model and UI tool. >> >> What may need attention is serialization to text file. Right now, the Ring >> 1 object returned by asRingDefinition (+ some tweaks) is serialized and >> materialized via STON into the .ombu files. With Ring 2 serialized with >> STON, the file format will be different and in consequence the new epicea >> won't be able to open a .ombu file generated in Ring 1. Not sure if Pharo >> community find this acceptable. IMO it is. >> - If not-acceptable, there could be some workaround. >> - If acceptable, that's the easiest path, and also it could be a good >> opportunity to improve the file format: It could be more compact and even >> have a better extension such as .epicea or something that comunicates that >> tthose files have code changes or sessions. > > > I think that the change of the format is not a a practical issue because > probably no-one will need to read the old Ombu files from a different Pharo > version. > But a change of the format will be handy because every Ring2 model is a > standalone environment and Ombu thus saves all information that it includes. > So a simple method change creates a record with almost 400 lines. It must be > of course much slower too. > > -- Pavel > >> >> cheers, >> MartÃn >> >>> >>> - The real system and the model is mixed many times in the users of the >>> old Ring. For example a model for a method is created but then when the >>> package of the method is asked, it is already a real package, not its model. >>> Such places need to be cleaned. >>> - I already have an image that has no old Ring code at all but because of >>> some memory leaks caused by the mixtures of the models and real system I was >>> not able to bootstrap it successfully. More work is needed. >>> - I discovered that the image has a serious memory leak caused by >>> Iceberg/GT and Announcers but I still need to find more information about >>> it. >>> >>> Smalltalk archeology >>> - during the free days on the beginning of the year I looked at >>> Smalltalk-78. I extracted the data from Lively Kernel so the original image >>> can read from external files, not only the recent updated ones. >>> - Then I looked at SqueakJS again and tried to reproduce Craig's >>> experiments with Pharo on it. Generally it is about 100 times slower than >>> native Pharo which makes it hard to use for real-life tasks. However it >>> would be pity to do not provide at least basic attention to it because in >>> some cases it may be really useful. >>> >>> Cheers, >>> -- Pavel >>> >>> >> >

Jan. 8, 2018

Mutation of symbols

by Norbert Hartl

What is the purpose of ByteSymbol>>#privateAt:put: ByteSymbol>>#string: WideSymbol>>#privateAt:put: WideSymbol>>#string: ? thanks, Norbert

Jan. 8, 2018

About values....

by Stephane Ducasse

https://youtu.be/keCwRdbwNQY I would love to have $ to market Pharo but I like this talk Stef

Jan. 8, 2018