August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Syntax Error: Message pattern expected

by Alistair Grant

Hi Johannes, On Wed, Aug 02, 2017 at 08:59:33PM +0000, Johannes Brauer wrote: > > > Am 02.08.2017 um 21:44 schrieb Alistair Grant <akgrant0710(a)gmail.com>: > > > > On Wed, Aug 02, 2017 at 12:22:38PM -0700, jb wrote: > >> Hi everyone! > >> > >> I get this error when I try to load a package from my Monticello rep. I have > >> never seen this before and have not a clue where to look for the mistake. > >> > >> The error message window show: > >> Object <none> > >> > >> Any hints what to do? > >> > >> Johannes > > > > Someone may recognise this and be able to answer it straight off, but > > otherwise... > > > > Supply: > > > > - Pharo version and image number (World Menu -> System -> About) > Pharo4.0 > Latest update: #40626 > > - OS > macOs 10.12.6 > > - PharoDebug.log (if possible delete the old version and recreate the > > error) > PharoDebug.log is empty > > BTW, I tried to do the same with > Pharo 6.0 > Latest update: #60508 > > Same behavior One more piece of information I should have requested: Steps to reproduce (or even better, code that reproduces) the problem. Cheers, Alistair

Aug. 3, 2017

Re: [Pharo-users] How to load a baseline in Iceberg? Get #addTo: sent to nil?

by Tim Mackinnon

It might be something in this area - I will have to study. I am using gitlab and have done a clone - so the packages are on my disk, but it did look like it wasnât properly finding them due to the naming of the local git url (so not quite your issue, but in a similar space I think). Iâm just surprised no-one else is mentioning this which makes me wonder if its my setup (although this is a vanilla zeroconf with nothing strange). I think you are supposed to be able to clone, then click on a baselineOf package and pick install - and this should get all your code into the image (thatâs why there is an install menu item just on baselineOF packages?) Tim > On 3 Aug 2017, at 09:09, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > This works for me (to load BaselineOfTowergame from src/ relative to image location): > > | hereRef | > hereRef := Smalltalk imageDirectory asFileReference. > > "Work around scp url hardwired 'git@'" > IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl > "Very simplistic implementation that does not cover all cases" > ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. > IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@'). > > (IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register. > > IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access" > > Iceberg enableMetacelloIntegration: true. > Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load: 'development'. > > Towergame configure. > > Smalltalk snapshot: true andQuit: true. > > You may not need the workarounds (first is for non-"git@" remote, second is for github:// not working without a github.com ssh access). > > Tim Mackinnon wrote: >> Iâm wondering if Iâm missing a trick somewhere - but I have a simple >> project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg >> (technically I donât need the BaseLineOf, but I was learning how to use >> them and I simply added a postLoad hook to run some code in it). >> >> Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in >> the UI. If I right click on the BaseLine one, and click the âinstall >> baseline (default)â option, I was expecting it to load both packages for >> me - however I get the talkback error â#addTo: was sent to nil from the >> MCRepositoryGroup>>addRepository: methodâ. >> >> In trying to debug the code I can see its trying to find a handler for >> gitlocal:///, doesnât find one and then tries to create a repo and >> bailsâ¦ this seems like a bug? I did notice in tracing the code that >> there is a reference to a Setting that I saw - âEnable Metacello >> Integrationâ - should I set that to true (its false by default)? >> >> Iâm wondering how other people are loading their projects in Iceberg if >> this doesnât work? >> >> Tim > >

Aug. 3, 2017

Re: [Pharo-users] [vwnc] Live Programming in Smalltalk development environments survey + raffle

by Juraj Kubelka

Hi Helge, we are targeting it to ICSE 2018. With crossed fingers it will happen :-) Cheers, Juraj > El 03-08-2017, a las 10:30, Nowak, Helge <HNowak(a)cincom.com> escribiÃ³: > > Dear Juraj, Romain and Alexandre, <> > > this is indeed an interesting piece of research! Where will you publish the results with detailed analysis? > > Cheers > Helge > > Helge Nowak > Cincom Smalltalk Technical Account Manager EMEA > <image001.png> <http://www.cincomsmalltalk.com/> > Cincom Systems GmbH & Co. oHG > Am Kronberger Hang 4 > 65824 Schwalbach/Ts. > GERMANY > office > mobile > fax > > website > email > +49 89 89 66 44 94 > +49 172 74 00 402 > +49 89 89 66 44 95 > > http://www.cincomsmalltalk.com <http://www.cincomsmalltalk.com/> > hnowak(a)cincom.com <mailto:hnowak@cincom.com> > A standpoint is an intellectual horizon of radius zero. -- Albert Einstein > > GeschÃ¤ftsfÃ¼hrer/Managing Directors: Thomas M. Nies, Donald E. Vick > oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht KÃ¶nigstein/Ts. HRA 2653) > Pers. haftender Gesellschafter/Partner liable to unlimited extent: > Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht KÃ¶nigstein/Ts. HRB 5069) > > --- CONFIDENTIALITY STATEMENT --- > This e-mail transmission contains information that is intended to be privileged and confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited, please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. > > > Von: Juraj Kubelka [mailto:juraj.kubelka@icloud.com] > Gesendet: Donnerstag, 3. August 2017 09:31 > An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>; Pharo Development List <pharo-dev(a)lists.pharo.org>; Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org>; squeak-dev(a)lists.squeakfoundation.org; vwnc(a)lists.cs.illinois.edu > Betreff: [vwnc] Live Programming in Smalltalk development environments survey + raffle > > â âWe are apologize for multiple copies.â â > > Dear Smalltalker, > > Live programming frees developers from the "edit-compile-run" loop and allows people to interact with running programs very easily. Live programming is getting popular, but many of its features have > been present in Smalltalk for a very long time. > > We want to understand how Smalltalk software developers use live programming features in practice. We would be grateful if you could participate in our 10-minute survey on this subject: > http://bit.ly/2ufcg2D <http://bit.ly/2ufcg2D> > > As a thank you for your participation, you will be able to participate in a raffle to win a Smalltalk book of your choice. If you wish to participate, you will need to share your email with us, so > that we can contact you. > We will appreciate if you share the survey > - Twitter post: https://twitter.com/JurajKubelka/status/893006267085709312 <https://twitter.com/JurajKubelka/status/893006267085709312> > - Facebook post: https://www.facebook.com/juraj.kubelka/posts/10212505941300008 <https://www.facebook.com/juraj.kubelka/posts/10212505941300008> > > By participating in the survey you will: > - help me to successfully finish my PhD, > - push Smalltalk awareness in Live Programming research community, > - bring new integrated electronic communication ideas, and > - bring new ideas to improve our Smalltalk Live Programming experience :-) > > We will close the survey on Wednesday, August 9, 2017 AoE. > > Thank you and we really hope you enjoy participating in our survey! > > Juraj Kubelka, PhD Student at the University of Chile > > Romain Robbes, Professor at Free University of Bozen-Bolzano > > Alexandre Bergel, Professor at the University of Chile

Aug. 3, 2017

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

by Andrei Chis

On Wed, Aug 2, 2017 at 2:37 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hey thanks - that seems like a good strategy (I hadnât though of sharing > the GT ones as well). > > *However, Iâm still curious how/why a new image would pick up settings > from what I did in another image (at least I think thats what its done - > certainly the directory it shows in my fresh image is not File > @pharo-local/package-cache like I would expect it to be?* > > With regards to the GT settings - how does it work if you share them - do > they happily co-exist? > They should co-exits with no issues if you share the play-cash and play-stash folders between multiple images. > The stash one is also quite new to me - Sven mentioned it a few weeks ago > as I was confused how the playground got saved (Iâm still not clear) - but > he suggested double-clicking the title and giving the tab a name. Are these > named ones the stashed ones (it looks like it). And do stashed ones honour > cmd-s to save them? Which then leads to the question, that in different > images - if you share the stash then I guess if you want to reload a file, > you close that playground and then pick it again from the list? > The play-stash is for scripts you explicitly give a name. You can double click on the tab and enter a name. Then a file with that name plus a timestamp is created in the play-stash folder. The content gets then saved to that file. Right now you can access the stashed scripts again though spotter by searching for the script name or typing #play to get the cached and stashed pages. Cheers, Andrei > > Its quite a cool way of working (not perfect) but a real time saver. > Thanks for sharing. > > Tim > > On 2 Aug 2017, at 13:24, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi - Iâve noticed that when I download a new image+vm with zeroconf (in a >> fresh directory) - that when I launch it, the setting Tools | Software >> Config Mgnmnt | Monticello | Local Cache Directory has a value that points >> to a directory from one of my earlier images. >> >> Is this normal (does it store this information somewhere on my computer >> so that different setups can access it)? >> >> At first I thought this was annoying - but Iâm now wondering if this is >> useful as Iâm guessing that there isnât any reason to have separate caches >> for version controlled libraries and so maybe I should actually set it to >> some common directory? >> >> What is the recommended strategy? >> >> > My strategy is to use a shared repository for all my images. As part of my > build image scripts I do something like this: > > > " =============== Personal Settings ================ " > MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference.MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference.GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. > > GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' > asFileReference. > > > I guess you save stuff: > > find /Users/mariano/Pharo/localRepo/ -type f | wc -l > > *32301* > > du -sh /Users/mariano/Pharo/localRepo > *6.1G* /Users/mariano/Pharo/localRepo > > > Not only you save disk space, but also: > 1) Each image build is likely to take less time as many files will be > already in the cache (no need to redownload it). > 2) it works as a yet another backup of your code and other packages. > > > > -- > Mariano > http://marianopeck.wordpress.com > > >

Aug. 3, 2017

Re: [Pharo-users] Pharo 61 crashes on iceberg history

by Esteban Lorenzano

> On 3 Aug 2017, at 11:24, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Esteban Lorenzano wrote: >> Hi, >> >> can I have a reproducible case? > > IIRC, every click on a particular commit in history view just does that. not really, I use it everyday (well, not now since Iâm on holidays, but every other day). > >> and a bug report on https://github.com/pharo-vcs/iceberg/issues ? > > Not me, no github (and no plan to). then I will probably not remember issue because I cannot remember everything I see (I receive 150+ mails *a day*, imagine that in 20 days holidays). But if for real there is a crash so often, I will eventually hit it (or some other will eventually report it). cheers! Esteban > >> (so I do not forget when I comeback from holidays). >> >> cheers! >> Esteban >> >>> On 30 Jul 2017, at 21:37, herby(a)mailbox.sk <mailto:herby@mailbox.sk> wrote: >>> >>> Me, too. Primitive failure. 117, IIRC. >>> >>> On July 30, 2017 3:51:56 AM GMT+02:00, "JuliÃ¡n Maestri" <serpi90(a)gmail.com <mailto:serpi90@gmail.com>> wrote: >>>> I'm almost sure this is not the right place to report it. >>>> >>>> Im having a vm crash when looking at the history of a repository on >>>> iceberg. >>>> >>>> urpharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top >>>> (av) >>>>> && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && >>>> prev_inuse >>>>> (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' >>>> failed. >>>>> ./pharo-u > i: line 11: 2011 Aborted (core dumped) >>>>> "$DIR"/"pharo-vm/pharo" "$@" >>>>> >>>> >>>> Pharo downloaded from get.pharo.org/64/ <http://get.pharo.org/64/> on Ubuntu 16.04 (64bit) >>>> >>>> Has somebody had this problem? >>>> Where's the right place to report this? >>>> >>>> Thanks, JuliÃ¡n >>> >> > > >

Aug. 3, 2017

Re: [Pharo-users] Iceberg and removing packages

by Esteban Lorenzano

so, this is probably a bug. are you using latest iceberg version? (it should be 0.5.5â¦ the one present on P6.1) Esteban > On 3 Aug 2017, at 00:32, Tim Mackinnon <tim(a)testit.works> wrote: > > I just hit the same problem - I wanted to remove a package that I no longer wanted - I went to the iceberg packages tab for the project and picked remove from disk and then I did a synchronise and commit. At the time I did notice that it didnât show a package removal change (but I assumed that as it was gone, maybe you donât show that?). > > Tim > >> On 31 Jul 2017, at 13:30, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Did you commit? >> >>> On 31 Jul 2017, at 14:06, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> That's exactly what I did. But after synchronizing the repo, the >>> package wasn't listed on Iceberg but it still was in in the repo. >>> It happened with another package in another repo as well. >>> >>> If it happens again I'll let you know. >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >>> >>> 2017-07-31 7:03 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> Hi, >>>> >>>> In iceberg, you have to go to package tab and say "remove package from disk" >>>> >>>> Esteban >>>> >>>>> On 30 Jul 2017, at 17:01, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>>> >>>>> I got into the pharo-local/iceberg/... and git rm'ed the directory, >>>>> commited and synchronized the project in Iceberg. >>>>> >>>>> I hope it doesn't break anything since I don't know how much "magic" >>>>> does Iceberg behind the scenes other than automating the git commands >>>>> and providing a centralized UI. >>>>> >>>>> What is the "This is all you need to read to understand Iceberg?" >>>>> document I should read? I read its wiki, but it seems there is more to >>>>> go. >>>>> >>>>> Regards! >>>>> >>>>> Esteban A. Maringolo >>>>> >>>>> >>>>> 2017-07-30 11:28 GMT-03:00 Peter Uhnak <i.uhnak(a)gmail.com>: >>>>>> This was supposedly fixed in April https://github.com/pharo-vcs/iceberg/issues/317 >>>>>> >>>>>> however I had the same issue ~two months ago, so I had to delete the packages by hand. >>>>>> >>>>>> P >>>>>> >>>>>> >>>>>>> On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm playing around with Iceberg in Pharo 6, and even when I find the >>>>>>> workflow streamlined, but since it doesn't map 1:1 with git workflow >>>>>>> from other IDEs or command line, I find myself not knowing how to do >>>>>>> certain tasks. >>>>>>> >>>>>>> One thing that happened is that I published a few packages to one of >>>>>>> my repos in Github, then I decided to remove one of the packages from >>>>>>> the repo, then I synchronized it but in the repo there is still is the >>>>>>> package folder for the package I removed. >>>>>>> >>>>>>> What should I do to definitely remove those files from the commit? >>>>>>> >>>>>>> Regards! >>>>>>> >>>>>>> Esteban A. Maringolo >>>>>>> >>>>>> >>>>> >>>> >>> >> > >

Aug. 3, 2017

Re: [Pharo-users] Pharo 61 crashes on iceberg history

by Herby VojÄÃk

Esteban Lorenzano wrote: > Hi, > > can I have a reproducible case? IIRC, every click on a particular commit in history view just does that. > and a bug report on https://github.com/pharo-vcs/iceberg/issues ? Not me, no github (and no plan to). > (so I do not forget when I comeback from holidays). > > cheers! > Esteban > >> On 30 Jul 2017, at 21:37, herby(a)mailbox.sk <mailto:herby@mailbox.sk> >> wrote: >> >> Me, too. Primitive failure. 117, IIRC. >> >> On July 30, 2017 3:51:56 AM GMT+02:00, "JuliÃ¡n Maestri" >> <serpi90(a)gmail.com <mailto:serpi90@gmail.com>> wrote: >>> I'm almost sure this is not the right place to report it. >>> >>> Im having a vm crash when looking at the history of a repository on >>> iceberg. >>> >>> urpharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top >>> (av) >>>> && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && >>> prev_inuse >>>> (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' >>> failed. >>>> ./pharo-u i: line 11: 2011 Aborted (core dumped) >>>> "$DIR"/"pharo-vm/pharo" "$@" >>>> >>> >>> Pharo downloaded from get.pharo.org/64/ <http://get.pharo.org/64/> >>> on Ubuntu 16.04 (64bit) >>> >>> Has somebody had this problem? >>> Where's the right place to report this? >>> >>> Thanks, JuliÃ¡n >> >

Aug. 3, 2017

Re: [Pharo-users] Pharo 61 crashes on iceberg history

by Esteban Lorenzano

Hi, can I have a reproducible case? and a bug report on https://github.com/pharo-vcs/iceberg/issues <https://github.com/pharo-vcs/iceberg/issues> ? (so I do not forget when I comeback from holidays). cheers! Esteban > On 30 Jul 2017, at 21:37, herby(a)mailbox.sk wrote: > > Me, too. Primitive failure. 117, IIRC. > > On July 30, 2017 3:51:56 AM GMT+02:00, "JuliÃ¡n Maestri" <serpi90(a)gmail.com> wrote: >> I'm almost sure this is not the right place to report it. >> >> Im having a vm crash when looking at the history of a repository on >> iceberg. >> >> urpharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top >> (av) >>> && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && >> prev_inuse >>> (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' >> failed. >>> ./pharo-ui: line 11: 2011 Aborted (core dumped) >>> "$DIR"/"pharo-vm/pharo" "$@" >>> >> >> Pharo downloaded from get.pharo.org/64/ on Ubuntu 16.04 (64bit) >> >> Has somebody had this problem? >> Where's the right place to report this? >> >> Thanks, JuliÃ¡n >

Aug. 3, 2017

Re: [Pharo-users] How to load a baseline in Iceberg? Get #addTo: sent to nil?

by Herby VojÄÃk

This works for me (to load BaselineOfTowergame from src/ relative to image location): | hereRef | hereRef := Smalltalk imageDirectory asFileReference. "Work around scp url hardwired 'git@'" IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl "Very simplistic implementation that does not cover all cases" ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@'). (IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register. IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access" Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load: 'development'. Towergame configure. Smalltalk snapshot: true andQuit: true. You may not need the workarounds (first is for non-"git@" remote, second is for github:// not working without a github.com ssh access). Tim Mackinnon wrote: > Iâm wondering if Iâm missing a trick somewhere - but I have a simple > project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg > (technically I donât need the BaseLineOf, but I was learning how to use > them and I simply added a postLoad hook to run some code in it). > > Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in > the UI. If I right click on the BaseLine one, and click the âinstall > baseline (default)â option, I was expecting it to load both packages for > me - however I get the talkback error â#addTo: was sent to nil from the > MCRepositoryGroup>>addRepository: methodâ. > > In trying to debug the code I can see its trying to find a handler for > gitlocal:///, doesnât find one and then tries to create a repo and > bailsâ¦ this seems like a bug? I did notice in tracing the code that > there is a reference to a Setting that I saw - âEnable Metacello > Integrationâ - should I set that to true (its false by default)? > > Iâm wondering how other people are loading their projects in Iceberg if > this doesnât work? > > Tim

Aug. 3, 2017

Problem with ThreadPool on os windows - no execution

by Sabine Manaa

Hi, because of [1] I use ThreadPool [2] and while developing on my mac it worked fine. But now, testing it on my production server which is a windows machine, it does not work which means, it is some kind of magic, the code within the block [anObject doSomething] queueWork is not run. When changing it to [anObject halt doSomething] queueWork the code is run! Changing my code from >>queueWork back to >>fork proves that everything is fine now and there is a problem with ThreadPool. When I was playing around to find the problem, I noticed the following: I created a button like this: html mdlButton onClick: (html jQuery ajax script: [ :script | | theSession | theSession := self session. [ theSession inspect ] queueWork. ]); with: 'test' Mac: it works nearly immediately Windows: it does not work ... except when I add a halt in it but: When I then do this after clicking on the test button: 20 timesRepeat: [[ Transcript crShow: Time now printString] queueWork ], the sessions inspector also comes up It seems that the process is hanging until the next work is to be done. Before going deeper in it my question is: does anyone use it on windows? is it made for windows, too? are there any experiences with windows and ThreadPool? did I miss something? how can I fix this? Regards Sabine [1] http://forum.world.st/ThreadPool-with-Seaside-how-td4956812.html#a4957192 [2] http://smalltalkhub.com/#!/~pdebruic/ThreadPool/

Aug. 3, 2017