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

Voyage-UnQLite hangs on Windows

by Marco HÃ¶rning

I started evaluating Voyage-UnQLite, current Pharo 6.1, Windows 10 installed: Metacello new repository: 'github://pharo-nosql/voyage/mc'; baseline: 'Voyage'; load: 'unqlite tests'. Using latest dll (Aug 10, 2016) https://github.com/pharo-nosql/PunQLite/commits/master/binary/win/unqlite.d… Basic test trying to store and reload a simple object containing a string instance variable Object subclass: #SomeTag instanceVariableNames: 'designation' SomeTag class>>isVoyageRoot ^ true Here's the Testcase code: VoyageTest>>setUp repository := VOUnQLiteRepository on: FileSystem workingDirectory / 'TestDatabase.db'. repository open VoyageTest>>tearDown repository close Running tests now: VoyageTest>>testVoyageUnQLiteStartup self assert: repository isOpen that works, db an be opened and closed. Now trying to store an object.... VoyageTest>>testVoyageUnQLiteWrite | aTag | self assert: SomeTag isVoyageRoot. aTag := SomeTag new designation:'aTag'. repository save: aTag works, if I open a Database (PunQLite) Browser it shows me the entries 'SomeTag' and 'SomeTag_0'. Trying to load the object.... VoyageTest>>testVoyageUnQLiteRead | fetchedTags | fetchedTags := repository selectAll:SomeTag that does not work. System hangs and I get a Testcase timeout with a "TestTookTooMuchTime" exception. the external call in UnQLilteFFI>>array: pArray walk: xWalk data: pUserData does not come back. Any comments or bright ideas what's wrong ? Anybody experience with Voyage-UnQLite on Windows ? Kind Regards from Germany Marco

June 20, 2018

Re: [Pharo-users] [ANN] Pharo Launcher v1.2 release

by Sean P. DeNigris

demarey wrote > I just released PharoLauncher 1.2 Thanks! Warning to users: This new release is based on 64-bit Pharo. This caused a bit of unexpected havoc for me as my projects are not all tested on 64-bit. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 20, 2018

Re: [Pharo-users] Lost in stream

by Hilaire

No with Pharo, and pretty old XML parser version. But still this one was always capable to parse entity Le 18/06/2018 Ã 02:43, monty a Ã©critÂ : > Are you developing in Squeak? I ask because the XML parser in the default Squeak image is very old. You can download the latest Pharo XMLParser lib from the SqueakMap. It's the "XMLParser" project. Other libs I maintain are also available as SM projects, like "XMLParser-XPath". > > If you're doing DOM parsing, you can save a parsed DOM document to a file using a message like #printToFileNamed: (see the XMLNode "printing" category for more). -- Dr. Geo http://drgeo.eu

June 20, 2018

Re: [Pharo-users] How to contribute to Calypso when it relies on pharo-core editors?

by Guillermo Polito

On Wed, Jun 20, 2018 at 1:47 PM Ben Coman <btc(a)openinworld.com> wrote: > > > On 20 June 2018 at 15:38, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi Tim, >> >> Yes, there you're experiencing the limits of our current process. We were >> studying the usage of git subtrees/submodules/subrepos but none of them >> seem a satisfying solution for what would give us a smooth contribution >> process. >> >> Now, we can enhance a bit the current status by adding calypso in the >> list of iceberg projects. I agree with this. Actually putting Pharo and >> Iceberg itself there is something we started to do slowly. There was this >> feeling that people would complain "agh but I only want to see my projects >> not the system ones". What I believe is that we are used to see and change >> all packages in the system, that's in our "blood" as pharoers. So seeing >> all loaded projects may confuse a bit newcomers but empower experts too... >> > > Just random musing... > It must be common that projects depend on several repos, so perhaps > Iceberg could present repos in a two level tree. > The first level is a "project" of which "Pharo" would be one, with second > level holding Iceberg and Calypso. > This could be condensed by default so that adding extra default Pharo > system repos doesn't clutter much. > If this could somehow tie in with tracking the repos loaded by Baselines, > that would be super cool. i.e. Baseline=Project. > We are adding the idea of projects to iceberg in the release 1.2 ;) The idea so far is that an iceberg project will remember at first what is the code subdirectory (so people don't have to type it all over!). But this opens the idea to have composite projects in the future. > Then we don't use the existing subtree/submodule/subrepos, just > baselines. > After all, those three standard options all started out as separate > scripts tacked onto git - its flexible like that. > Well, yes and no. That does not quite solve the issue. Reifying projects add some flexibility, but it does not handle inter git-repository dependencies. The case is the following: - pharo is stored in pharo-project/pharo.git - calypso is stored in pharo-contributions/calypso.git Regardless how you show them in the UI, let's suppose now that you want to do a change that involves both. Scenario 1) That is, you have: pharo v1 calypso v1 And you want to pharo v2 calypso v2 If the change in either is dependent on the other, and/or for example breaks backwards compatibility, this means there is an implicit dependency between pharo and calypso. But, next time you build pharo, you load v2, and then you find yourself with: pharo v2 calypso v1 And everything breaks :) Scenario 2) This could be solved by first doing a calypso release marking v2, and once that release is finished and public, doing a new pharo v2 release with the proper calypso version. But now, all this "administrative cost" means that there is a time gap between the release of calypso v2 and the release of pharo v2. In this moment, if you just load bleeding edge version, you may have a build with: pharo v1 calypso v2 Which may also break if proper care with backwards compatibility was not taken! Nowadays, both calypso and Iceberg are managed like in *scenario 2*. This adds some some safety and order at the cost of bureaucracy (partial releases, care for backwards compatibility). Generally speaking, I'd like in the future a solution where there is a good tradeoff between safety and flexibility/speed. Guille

June 20, 2018

Re: [Pharo-users] How to contribute to Calypso when it relies on pharo-core editors?

by Ben Coman

On 20 June 2018 at 15:38, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Tim, > > Yes, there you're experiencing the limits of our current process. We were > studying the usage of git subtrees/submodules/subrepos but none of them > seem a satisfying solution for what would give us a smooth contribution > process. > > Now, we can enhance a bit the current status by adding calypso in the list > of iceberg projects. I agree with this. Actually putting Pharo and Iceberg > itself there is something we started to do slowly. There was this feeling > that people would complain "agh but I only want to see my projects not the > system ones". What I believe is that we are used to see and change all > packages in the system, that's in our "blood" as pharoers. So seeing all > loaded projects may confuse a bit newcomers but empower experts too... > Just random musing... It must be common that projects depend on several repos, so perhaps Iceberg could present repos in a two level tree. The first level is a "project" of which "Pharo" would be one, with second level holding Iceberg and Calypso. This could be condensed by default so that adding extra default Pharo system repos doesn't clutter much. If this could somehow tie in with tracking the repos loaded by Baselines, that would be super cool. i.e. Baseline=Project. Then we don't use the existing subtree/submodule/subrepos, just baselines. After all, those three standard options all started out as separate scripts tacked onto git - its flexible like that. cheers -ben

June 20, 2018

Re: [Pharo-users] Cargo

by Christophe Demarey

Hi Norbert, Sadly, Iâm late on this project. I recently did a model refactoring to Cargo to focus on most wanted features: - git support - loadable project (and dependencies) without having a cargo package repository, i.e. only loading code from git repositories - metacello support : let Cargo use Metacello to load configurations / baselines when no cargo description is available. I will start very soon to test this new model with Pharo Launcher. If everything is fine, then I hope to integrate Cargo into Pharo 7 so that people can start to play with it and give feedback. By talking to other people, it looked that Cargo alone, without a compatibility layer with Metacello would be hard to use. Cheers, Christophe > Le 20 juin 2018 Ã 08:55, Norbert Hartl <norbert(a)hartl.name> a Ã©crit : > > Here comes my every-no-and-then-inquiry of the status of cargo. Is it in pharo7? Is it usable? > > Norbert >

June 20, 2018

Re: [Pharo-users] [ANN] Pharo Launcher v1.2 release

by Christophe Demarey

> Le 20 juin 2018 Ã 10:48, Serge Stinckwich <serge.stinckwich(a)gmail.com> a Ã©crit : > > On Wed, Jun 20, 2018 at 9:04 AM Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: > >> Le 19 juin 2018 Ã 16:28, Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> a Ã©crit : >> >> I dl the 64 bits VM for macOS. Everytime I run a 32 bits image, I have a warning that using a 32 bits images, require a 32 bits VM. >> And then when I select yes, everything works. Why having this warning everytime ? > > I added this warning so that people are aware that they use 32-bit images on a 64-bit system. We are moving to mostly 64-bit images. > The biggest concern for this warning was raised by a Linux user: he installed a 64-bit Pharo Launcher and was surprised to not be able to launch 32-bit images. Indeed, on linux, you need additional set up (i.e. install 32-bit libraries) to be able to launch 32-bit images. > > I understand thi warning could be annoying. Maybe I should add a setting to ignore these warnings? Would it be enough? Or should I only warn on Linux where it is really important? But in this case, people could may not be aware of using 32 or 64 bits images. > > > âYes maybe only have the warnings on Linux made more sense. â > > Could you open an issue for that? > > âOk done here:â ââhttps://github.com/pharo-project/pharo-launcher/issues/129 <https://github.com/pharo-project/pharo-launcher/issues/129> ok, thank you

June 20, 2018

Re: [Pharo-users] [ANN] Pharo Launcher v1.2 release

by Serge Stinckwich

On Wed, Jun 20, 2018 at 9:04 AM Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > > Le 19 juin 2018 Ã 16:28, Serge Stinckwich <serge.stinckwich(a)gmail.com> a > Ã©crit : > > Thank you Christophe for your work ! > I really appreciate it. > > I dl the 64 bits VM for macOS. Everytime I run a 32 bits image, I have a > warning that using a 32 bits images, require a 32 bits VM. > And then when I select yes, everything works. Why having this warning > everytime ? > > > I added this warning so that people are aware that they use 32-bit images > on a 64-bit system. We are moving to mostly 64-bit images. > The biggest concern for this warning was raised by a Linux user: he > installed a 64-bit Pharo Launcher and was surprised to not be able to > launch 32-bit images. Indeed, on linux, you need additional set up (i.e. > install 32-bit libraries) to be able to launch 32-bit images. > > I understand thi warning could be annoying. Maybe I should add a setting > to ignore these warnings? Would it be enough? Or should I only warn on > Linux where it is really important? But in this case, people could may not > be aware of using 32 or 64 bits images. > > âYes maybe only have the warnings on Linux made more sense. â Could you open an issue for that? > âOk done here: â â âhttps://github.com/pharo-project/pharo-launcher/issues/129 -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

June 20, 2018

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

by Guillermo Polito

On Thu, Jun 14, 2018 at 10:17 AM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Guille - I have tried the repo browser with the new iceberg loaded in > Pharo 6.1 and I couldnât see how it helps me? (I will make a firm point of > using 7 now as I think Iâve now got a reasonable grasp of how things should > work). > >From the threads below - how would I find the commit with my missing class > - Sean has pointed me to a git query that helps with that (and presumablyq > is something we can plug into iceberg - maybe I will even take a look). > > git log --full-history -- */{{className}}.class/properties.json Yes, this is definitely *doable* but nobody made the effort to do it yet. Doing it well should take into account what format the code is stored (filetree/tonel) and consider that the format would have changed in the middle of the history. If somebody wants to give it a try I can give some advice. > > Having identified the hash with the class I want - getting to it is > awkward (there is no search - again pretty easy for us to plug in, but > something to do) > Yes, I've found this issue that also in the past. It's not common to me to be looking for a commit like that, and when it is the UI is cumbersome. >From the backend, you can always inspect the repository and do repository lookupCommit: aCommitishString For example: repository lookupCommit: '726254360c987b9b3472a6098b5869970e819cc9' > Having got to my commit - how can I retrieve one class? Maybe this is > something only in Pharo 7 with Calypso? All I can see are diffs - so Iâd > have to copy and paste 20 methods and a class def. doable, but painful. > Iâm hoping there is a way to get a shadow copy of the commit from the tonel > file and then use it to restore classes and methods? As this sounds like a > decent chunk of work, Iâm guessing itâs not done yet? > Well on the items of the diff you have a "Revert change" option. That should work on most of the cases. I know that it would be also useful to be able to easily browse a commit. I've opened an issue. https://github.com/pharo-vcs/iceberg/issues/872 For the moment what I do from the backend (inspecting): aCommit fileSystem and you'll get a file system on the commit. So you'll see the exact files of the commit but "uniterpreted". That is, packages will be seen as repositories and not as packages. > > As a fallback, Any thoughts on why git wonât let me checkout a file from > that commit? Something about the pathspec (is it mangled in some way)? > I don't quite understand. Can you paste here your command? > And if I could restore a tonel file - would iceberg then recognise it to > bring it back in, > Nope, Iceberg never reads from the disk working copy. Iceberg reads directly from te blob. > or Would I need to use some filestream foo to do that (as this would at > least be a viable workaround for now)? > You can try to read it using Tonel? I don't know exactly how to use tonel directly, I'll let others answer better. > > Tim > > Sent from my iPhone > > > > Sent from my iPhone > On 14 Jun 2018, at 08:52, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi, > > Regarding history, right now we have a history browser implemented as a > Calypso plugin, that is open using context menu => history or the little > box button on the top right of the method pane (second button from the left > in the picture): > > <Screen Shot 2018-06-14 at 09.34.24.png> > > That button will nowadays only be shown if the method's package is linked > to an iceberg repository. > Once you click it, you will have the entire history of the method. > > <Screen Shot 2018-06-14 at 09.47.46.png> > > With the possibility to install that version of the method (among others). > > Now, regarding the recovery of deleted classes/methods, have you tried the > repository browser? > Go to Iceberg, right click on a repository and select "Repository". > You can there select a commit in history and then in the tabs below see > the diff between > - your current version and the selected commit > - the selected commit and its main parent > > Of course any of these can be improved, but if you have concrete requests, > it is much easier :) > > https://github.com/pharo-vcs/iceberg > > Guille > > On Wed, Jun 13, 2018 at 11:22 PM Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi Sean - I tried it again, and it worked: >> >> git log --full-history -- */PrismicBlock.class* >> >> (I got my wildcard slightly wrong for tonel format) - although the beauty >> of the one I gave was that it shows you all deleted classes (in case you >> donât know the name) >> >> Iâm still confused why I canât checkout the deleted class though - damn >> you git, for the cryptic error: : error: pathspec 'PrismicDemo/ >> PrismicBlock.class.st' did not match any file(s) known to git. >> >> I was hoping a quick hack to iceberg might be to OSProcess a few choice >> git commands to help us along while we work out better ways to do things. >> >> Tim >> >> On 13 Jun 2018, at 21:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Tim Mackinnon wrote >> >> I didnât quite get your fu to work >> >> >> Interesting. >> >> When I searched for commits affecting the deleted class SuDebianKey: >> >> $ git log --full-history -- */SuDebianKey.class/properties.json >> >> I got back a list of commits (obviously with the last chronologically >> being >> the deletion): >> >> commit a38fbced4abec59ff9879d4c607da80dc89b6637 >> Author: Sean DeNigris <sean(a)Seans-MBP.home> >> Date: Mon Jan 30 17:13:58 2017 -0500 >> >> Extract Lots to ComputerWorld, Absorb Rest of Old ScriptingBase Project >> >> commit 61175745d57c60a1707d5e2f9a2fc92e6c19a6ea >> Author: Sean DeNigris <sean(a)clipperadams.com> >> Date: Sat Aug 20 17:14:12 2016 -0400 >> >> Basket O' Enhancements >> ... >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 20, 2018

Re: [Pharo-users] Nice catchy video for covering Pharo capability

by Serge Stinckwich

You can have a look to the work of Oleks : https://github.com/PolyMathOrg/DataFrame and the video here: https://www.youtube.com/watch?v=H-bVVqPPsY8&list=PL4actYd6bfnzoYJYjSRxLezkY… On Tue, Jun 19, 2018 at 11:14 PM Andrei Stebakov <lispercat(a)gmail.com> wrote: > Could you suggest a nice video for a presentation to showcase Pharo as a > nice language for data visualization? > > Thanks, > Andrei > > -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

June 20, 2018