- Pharo-users - lists.pharo.org

Re: [Pharo-users] hard reset class variable state

by Ben Coman

btw2, I submitted this to PharoLauncher repo. cheers -ben On Thu, Aug 3, 2017 at 9:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > btw, for the archives, I ended up using... > > packages := RPackageOrganizer default packages select:[:p| > (p name includesSubstring: 'PharoLauncher') ]. > packages do: [:p| p definedClasses do:[:class| > class classPool keys do: [ :k | class classPool at: k put: nil ] ]]. > > cheers -ben > > On Sat, Jul 29, 2017 at 11:22 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> thx guille. >> >> On Sat, Jul 29, 2017 at 9:40 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Actually class variables are stored in a dictionary in a class. You can >>> access that by saying: >>> >>> aClass classPool. >>> >>> So resetting all values of a class variable could be easily done with >>> something like >>> >>> aClass classPool keys do: [ :k | aClass classPool at: k put: nil ]. >>> >>> Maybe that could be a nice addition. >>> >>> On Sat, Jul 29, 2017 at 9:51 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> I want to reset all the class variables in an application to nil. >>>> I've got as far as finding them, for example... >>>> >>>> packages := RPackageOrganizer default packages select:[:p| >>>> (p name includesSubstring: 'PharoLauncher') ]. >>>> stateToReset := packages flatCollect: [:p| >>>> p definedClasses >>>> select:[:c | (c classVarNames size > 0) and: [(c name >>>> includesSubstring: 'Configuration') not]] >>>> thenCollect:[:c| c-> c classVarNames] >>>> ]. >>>> stateToReset asDictionary keysAndValuesDo:[:class :variables| >>>> variables do: [:v| Transcript crShow: 'Clear ', class printString, ' -> >>>> ' , v printString]. >>>> ]. >>>> >>>> What could go in place of the Transcript line to set them to nil? >>>> >>>> cheers -ben >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> >>> Research Engineer >>> >>> 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 <+33%206%2052%2070%2066%2013> >>> >> >> >

Aug. 3, 2017

Re: [Pharo-users] hard reset class variable state

by Ben Coman

btw, for the archives, I ended up using... packages := RPackageOrganizer default packages select:[:p| (p name includesSubstring: 'PharoLauncher') ]. packages do: [:p| p definedClasses do:[:class| class classPool keys do: [ :k | class classPool at: k put: nil ] ]]. cheers -ben On Sat, Jul 29, 2017 at 11:22 PM, Ben Coman <btc(a)openinworld.com> wrote: > thx guille. > > On Sat, Jul 29, 2017 at 9:40 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Actually class variables are stored in a dictionary in a class. You can >> access that by saying: >> >> aClass classPool. >> >> So resetting all values of a class variable could be easily done with >> something like >> >> aClass classPool keys do: [ :k | aClass classPool at: k put: nil ]. >> >> Maybe that could be a nice addition. >> >> On Sat, Jul 29, 2017 at 9:51 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> I want to reset all the class variables in an application to nil. >>> I've got as far as finding them, for example... >>> >>> packages := RPackageOrganizer default packages select:[:p| >>> (p name includesSubstring: 'PharoLauncher') ]. >>> stateToReset := packages flatCollect: [:p| >>> p definedClasses >>> select:[:c | (c classVarNames size > 0) and: [(c name includesSubstring: >>> 'Configuration') not]] >>> thenCollect:[:c| c-> c classVarNames] >>> ]. >>> stateToReset asDictionary keysAndValuesDo:[:class :variables| >>> variables do: [:v| Transcript crShow: 'Clear ', class printString, ' -> >>> ' , v printString]. >>> ]. >>> >>> What could go in place of the Transcript line to set them to nil? >>> >>> cheers -ben >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> 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 <+33%206%2052%2070%2066%2013> >> > >

Aug. 3, 2017

Re: [Pharo-users] Glorp reconnection management (was: Re: Glorp: how to reconnect after image shutdown / load?)

by Herby VojÄÃk

Pierce Ng wrote: > On Wed, Aug 02, 2017 at 11:30:27AM +0200, Herby VojÄÃk wrote: >> Hm, I though that once I open a session it does actually connect on >> demand (it has Login, system and all the information for it). Does >> it actually mean that if I want to stay connected I must do `session >> login` before each `session inUnitOfWorkDo:`? > > No. Great. >> As written above, I thought glorp manages this kind of reconnection >> itself. If not, can someone point me to the some example where this >> is managed? I am asking because in Glorp book I did not find >> anything about this (I have read it). > > If used with Seaside, typically when a Seaside session is started, your > application's custom subclass of WASession starts a database session, be it for > Glorp, some other OODB, good olde SQL, etc. From Sven's Reddit.st: > > RedditSession>>glorpSession > glorpSession ifNil: [ glorpSession := self newGlorpSession ]. Yeah, I ended up with this. And planning to set it to nil on each image loading (not sure how, yet, I don't want to register a class as a handler, but I'll manage, I hope). > glorpSession accessor isLoggedIn > ifFalse: [ glorpSession accessor login ]. Looking at state of the art code: DatabaseAccessor >> login | | self loginIfError: [:ex | ex pass]. "Just to help avoid confusion if someone thinks they're getting a login object back from this" ^nil. GlorpSession >> isLoggedIn ^accessor isLoggedIn GlorpSession >> login self isLoggedIn ifTrue: [^nil]. ^self loginIfError: [:ex | ex pass] GlorpSession >> loginIfError: aBlock | result | result := self accessor loginIfError: aBlock. system platform characterEncoding: accessor encoding. ^result it seems this `... ifFalse: ...` is in fact the same thing as `glorpSession login` (yes, it does set an encoding, but otherwise, it's the same, isn't it)? Doesn't this counter the previous "no", in fact? If I do all operations via `self glorpSession doSomething`, then it actually does `glorpSession login` before each action... > ^ glorpSession > > See the senders of #glorpSession. > > Also read the chapters of HPI's Seaside tutorial on tasks& sessions, and > persistence. > > http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial 1. Link does not load. 2. I am doing it with ZnServer, no Seaside there. > Pierce Thanks, Herby

Aug. 3, 2017

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

by Alistair Grant

Hi Tim, On Thu, Aug 03, 2017 at 10:55:09AM +0100, Tim Mackinnon wrote: > 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?) I don't know the original intent, but I've never thought about Iceberg this way. My understanding is that baselineOf: is intended for use by metacello. Iceberg allows you to load individual packages, but it's focus area is code development, not package loading. I use Iceberg to load the baseline package, edit it, then save it back to the git repository, then load the entire project through metacello (usually in separate images so I'm testing in a clean environment). HTH, Alistair > 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] Glorp reconnection management (was: Re: Glorp: how to reconnect after image shutdown / load?)

by Pierce Ng

On Wed, Aug 02, 2017 at 11:30:27AM +0200, Herby VojÄÃk wrote: > Hm, I though that once I open a session it does actually connect on > demand (it has Login, system and all the information for it). Does > it actually mean that if I want to stay connected I must do `session > login` before each `session inUnitOfWorkDo:`? No. > As written above, I thought glorp manages this kind of reconnection > itself. If not, can someone point me to the some example where this > is managed? I am asking because in Glorp book I did not find > anything about this (I have read it). If used with Seaside, typically when a Seaside session is started, your application's custom subclass of WASession starts a database session, be it for Glorp, some other OODB, good olde SQL, etc. From Sven's Reddit.st: RedditSession>>glorpSession glorpSession ifNil: [ glorpSession := self newGlorpSession ]. glorpSession accessor isLoggedIn ifFalse: [ glorpSession accessor login ]. ^ glorpSession See the senders of #glorpSession. Also read the chapters of HPI's Seaside tutorial on tasks & sessions, and persistence. http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial Pierce

Aug. 3, 2017

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