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

Re: [Pharo-users] Compiling lots of method source without debugger

by Henrik Sperre Johansen

Patrick Scherer wrote > Hello everyone, > > This is my first time here so I hope this is the right place to ask > questions. > > In an attempt to move lots of code from VA Smalltalk to Pharo, I need to > compile a lot of methods whose code may or may not work due to missing > classes in Pharo etc. > I want to be able to compile these methods programatically without > interruptions (using method source strings only) and gather all compiler > errors that occur. What would be the best way to go about this? > > Also: How do I control in which package a compiled method ends up if the > target class is in a different package (Method extension)? > > Any help would be greatly appreciated! > > Kind regards, > Patrick Scherer IIRC, Stephanne recently listed preservation of unloaded supers / extensions of unloaded classes as an area the INRIA group was working on, with a paper scheduled for ESUG, he might be able to help. I also recently went through roughly the same to import VSE code (for inspection in Moose, not execution). Can't say it was the best way, but I ended up creating a custom CodeImporter with several error/notification handlers around the "normal" loading code, and modifying the base system to raise said exceptions at appropriate places (rather than as currently, invoking dialogs directly) For instance, a MissingClass notification in MethodChunk >> handleMissingBehavior, and a MissingPool from TClass >> #sharing:, (both with defaultAction implemented as per current dialog-raising behavior, so they work the same unless explicitly handled). For my case, it was sufficient to have the handlers put classes/pools auto-generated by handlers in predetermined packages. The biggest pain / time drain was dealing with creating instvars in autogenerated classes when referenced from imported code (ie in methods on classes with missing superclasses) so the analysis wouldn't treat them as unknown globals, so if you don't initially need that, I'd skip it. I also did a compiler plugin to be able to rewrite certain selectors on import (mostly base class extensions from VSE clashing with existing implementations in Pharo), if you go that route, beware that the compiler doesn't really like you actually redefining source from outside an editor, and there will be some pains to have it store the correct(ed) source strings. To create a method as an extension in Package MyX, you need to give it a categoriy of *MyX (with an optional -originalCategory suffix if you want that) Good luck! Cheers, Henry -- View this message in context: http://forum.world.st/Compiling-lots-of-method-source-without-debugger-tp49… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 4, 2017

Compiling lots of method source without debugger

by Patrick Scherer

Hello everyone, This is my first time here so I hope this is the right place to ask questions. In an attempt to move lots of code from VA Smalltalk to Pharo, I need to compile a lot of methods whose code may or may not work due to missing classes in Pharo etc. I want to be able to compile these methods programatically without interruptions (using method source strings only) and gather all compiler errors that occur. What would be the best way to go about this? Also: How do I control in which package a compiled method ends up if the target class is in a different package (Method extension)? Any help would be greatly appreciated! Kind regards, Patrick Scherer

Aug. 4, 2017

Re: [Pharo-users] Iceberg and removing packages

by Esteban Lorenzano

> On 3 Aug 2017, at 19:13, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > How can I know which version it is loaded? > > My system version is: "Pharo6.0 of 13 May 2016 update 60508â this is old 6.0, you need 6.1(which is 60510) but then you need the new VM :S I checked: 0.5 fixes the problem of removing, but it fixes it bad: it removes correctly, but sync window shows no-changes (and commit will do the remove anyway). I will fix this once I come backâ¦ Esteban > > > Regards. > > > Esteban A. Maringolo > > 2017-08-03 6:27 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > 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 <mailto:estebanlm@gmail.com>> wrote: > >> > >> Did you commit? > >> > >>> On 31 Jul 2017, at 14:06, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@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 <mailto:estebanlm@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 <mailto:emaringolo@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 <mailto:i.uhnak@gmail.com>>: > >>>>>> This was supposedly fixed in April https://github.com/pharo-vcs/iceberg/issues/317 <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. 4, 2017

Re: [Pharo-users] Settings - Server Mode - should I use it?

by Tim Mackinnon

Hey Ben - thanks for sharing this with me - you know, I never knew you could right click on the settings and browseâ¦ Iâve always (only partially successfully) used haloâs on ui items and tried to dig in that wayâ¦ It turns out that in the minimal images that Pavel has been churning out - WorldState is not there (which makes sense, as you would expect all of the UI pieces to be stripped out). Tim > On 2 Aug 2017, at 18:09, Ben Coman <btc(a)openInWorld.com> wrote: > > hi Tim, > > This is Pharo! You can dig in to understand it yourself. ;) > 1. On the setting, right-click and "Browse". > 2. Scroll down to... label: 'Server mode' > then on #serverMode, right-click > Code Search > Implementors of it > 3. Looking at WorldState>>serverMode, click "Senders" > and you'll come to WorldState>>interCyclePause: > Look for senders of this and inspect MinCycleLapse. > > Basically that setting makes the UI loop delay for a longer time ==> less CPU > but I don't know whether that loop still runs in headless mode. > I guess if you are bootstrapping your Lambda image, you can choose. > > But since your Lambda is meant to finish quite quickly, alternatively maybe during image shutdown you could set a flag such that next startup #interCyclePause: blocks for 500ms and if the image exits cleanly and quickly, #doOneCycleNowFor: is never executed at all. > > cheers -ben > > On Wed, Aug 2, 2017 at 10:39 PM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi - I hadnât looked in the settings browser much before, but I was looking at what settings there were and noticed âserver modeâ. > > Should I be enabling this when building a headless server image to run on Lambda? I saw a 2016 post by John Brant that indicated it made a difference when doing some benchmarking in the image (presumably headful) - but Iâm wondering if when running headless on a server whether it really makes a difference. > > Has anyone played with this much before? > > Tim >

Aug. 4, 2017

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

by Stephane Ducasse

It may happen that you are trying to load an old package with a syntax error. We should improve the compiler infrastructure because I hate such error not You can bring the menu on the syntax error window and bring the debugger. (yes it is totally hidden and I hate it too). Stef On Wed, Aug 2, 2017 at 9:22 PM, jb <brauer(a)nordakademie.de> 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 > > > > -- > View this message in context: http://forum.world.st/Syntax-Error-Message-pattern-expected-tp4958351.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 4, 2017

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

by Johannes Brauer

I have got an image with my application running, so I could repair my rep. So, we can close the âissueâ. Cheers Johannes > Am 03.08.2017 um 20:45 schrieb Alistair Grant <akgrant0710(a)gmail.com>: > > On Thu, Aug 03, 2017 at 06:04:37PM +0000, Johannes Brauer wrote: >> Hi Ben, hi Alistair! >> >> Thank for your adjustment. In the meantime I looked backward in the version >> history and I found an older version which I can load without problems. Then I >> looked at the changes of the next higher version (producing the syntax error) >> and I found the following problem: >> [cid] >> Indeed, there is no message pattern, I have not a clue how something like that >> can happen. The question is: Can the repository be repaired? > > I've never really become familiar with mcz packages as I much prefer > git, so started using Iceberg as soon as possible, so someone else may > have a much better answer, however... > > It may be easier to load the previous version and manually apply the > changes in the latest version. If not... > > .mcz packages are just zip archives of a particular structure. You can > unzip the archive, find the corrupted method definition, manually fix > it, and re-zip the archive. It should then load. > > Cheers, > Alistair > > > > >> Johannes >> >> Am 03.08.2017 um 16:38 schrieb Ben Coman <btc(a)openinworld.com>: >> >> Hi Johannes, >> >> Is your Monticello repo public? Perhaps someone else could try to load the >> package to check something in it is not corrupt? >> >> cheers -ben >> >> On Thu, Aug 3, 2017 at 9:00 PM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >> >> 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

So I dont think I am going crazy - but there are so many different ways of working. I'll raise a bug in the morning. The trouble with enabling metacello support is that baselines aren't configs and so they don't have methods like #project that it seems to rely on. Tim Sent from my iPhone > On 3 Aug 2017, at 20:29, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> On Thu, Aug 03, 2017 at 05:28:33PM +0100, Tim Mackinnon wrote: >> Alistair - does that mean you?ve not tried using that menu item on a baseline >> package? I think its there for this reason - but maybe Esteban will comment >> when he?s back from holiday. > > OK, that's embarrassing... I didn't read your email properly, and no, I > hadn't tried it. > > The error occurs when Iceberg's metacello integration is disabled. So > if you execute: > > Iceberg enableMetacelloIntegration: true. > > And then load the baseline, it will work, although Iceberg doesn't > refresh its display properly. > > Can you open a fogbugz issue on the error case? > > >> So on a related front - do you go to a separate workspace and type in >> >> >> Metacello new >> baseline: ?MyBaseline'; >> repository: 'filetree://./local-project/src'; >> load. >> >> ? > > Yep, but normally in a completely separate image so that it is a clean > environment. I normally have a script that loads all the required > packages, so I can just: > > pharo-ui Pharo.image load_all.st > > In the development environment (where I'm using Iceberg) everything is > loaded, so I'm just testing the package functionality, not loading the > packages. > > > Cheers, > Alistair > > > >> I have tried loading all the packages in iceberg and then tried to load them >> with a script like this (but its very awkward - and I hadn?t thought of just >> using the Metacello variant) >> >> BaselineOfLambda project version spec packageSpecsInLoadOrder allButLast do: [ >> :s | >> s version load ]. >> >> >> >> >> On 3 Aug 2017, at 14:15, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> 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] How to load a baseline in Iceberg? Get #addTo: sent to nil?

by Alistair Grant

On Thu, Aug 03, 2017 at 05:28:33PM +0100, Tim Mackinnon wrote: > Alistair - does that mean you?ve not tried using that menu item on a baseline > package? I think its there for this reason - but maybe Esteban will comment > when he?s back from holiday. OK, that's embarrassing... I didn't read your email properly, and no, I hadn't tried it. The error occurs when Iceberg's metacello integration is disabled. So if you execute: Iceberg enableMetacelloIntegration: true. And then load the baseline, it will work, although Iceberg doesn't refresh its display properly. Can you open a fogbugz issue on the error case? > So on a related front - do you go to a separate workspace and type in > > > Metacello new > baseline: ?MyBaseline'; > repository: 'filetree://./local-project/src'; > load. > > ? Yep, but normally in a completely separate image so that it is a clean environment. I normally have a script that loads all the required packages, so I can just: pharo-ui Pharo.image load_all.st In the development environment (where I'm using Iceberg) everything is loaded, so I'm just testing the package functionality, not loading the packages. Cheers, Alistair > I have tried loading all the packages in iceberg and then tried to load them > with a script like this (but its very awkward - and I hadn?t thought of just > using the Metacello variant) > > BaselineOfLambda project version spec packageSpecsInLoadOrder allButLast do: [ > :s | > s version load ]. > > > > > On 3 Aug 2017, at 14:15, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > 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

Unknown variable warning with a method name when saving a method

by Myroslava Romaniuk

Hi, I'm trying to add the rewrite option to the Match Tool, and when I create a method and try to debug the code I get the following: So basically it tells me that the name of the method is an unknown variable which I don't get at all. And when I try to set it as a temporary variable just to see what I'll get, I actually get an error like this...Anyone has any idea what can be the problem? Thanks, Myroslava

Aug. 3, 2017

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

by Alistair Grant

On Thu, Aug 03, 2017 at 06:04:37PM +0000, Johannes Brauer wrote: > Hi Ben, hi Alistair! > > Thank for your adjustment. In the meantime I looked backward in the version > history and I found an older version which I can load without problems. Then I > looked at the changes of the next higher version (producing the syntax error) > and I found the following problem: > [cid] > Indeed, there is no message pattern, I have not a clue how something like that > can happen. The question is: Can the repository be repaired? I've never really become familiar with mcz packages as I much prefer git, so started using Iceberg as soon as possible, so someone else may have a much better answer, however... It may be easier to load the previous version and manually apply the changes in the latest version. If not... .mcz packages are just zip archives of a particular structure. You can unzip the archive, find the corrupted method definition, manually fix it, and re-zip the archive. It should then load. Cheers, Alistair > Johannes > > Am 03.08.2017 um 16:38 schrieb Ben Coman <btc(a)openinworld.com>: > > Hi Johannes, > > Is your Monticello repo public? Perhaps someone else could try to load the > package to check something in it is not corrupt? > > cheers -ben > > On Thu, Aug 3, 2017 at 9:00 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > 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