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

[Pharo 7.0-dev] Build #1159: 22295-Integrate-new-Iceberg-Version

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1159 was: SUCCESS. The Pull Request #1670 was integrated: "22295-Integrate-new-Iceberg-Version" Pull request url: https://github.com/pharo-project/pharo/pull/1670 Issue Url: https://pharo.fogbugz.com/f/cases/development Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 3, 2018

[Pharo 7.0-dev] Build #1158: 22294-MCTraitDefinition-is-not-correctly-initialised-in-all-the-constructors

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1158 was: FAILURE. The Pull Request #1669 was integrated: "22294-MCTraitDefinition-is-not-correctly-initialised-in-all-the-constructors" Pull request url: https://github.com/pharo-project/pharo/pull/1669 Issue Url: https://pharo.fogbugz.com/f/cases/22294 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 3, 2018

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

by Alistair Grant

Hi Guille, On Fri, Aug 03, 2018 at 10:34:22AM +0200, Guillermo Polito wrote: > Hi, > > I don't know the windows situation at all, but I'm wondering. > > ([ File stdioDescriptorIsATTY not ] > on: PrimitiveFailed > do: [ :ex | "HACK kept for retrocompatibility" Smalltalk os isWin32 ]) > ifTrue: [ ^ self createStdioFileFor: moniker ]. > > the first thing I would do, just trying to keep the same behaviour, is to > invert the test... Something like > > Smalltalk os isWin32 ifTrue: [ > [ File stdioDescriptorIsATTY not ] > on: PrimitiveFailed > do: [ :ex | false ]) > ifTrue: [ ^ self createStdioFileFor: moniker ]. ] > > Like that, this would only penalise windows in the worst case. True. Actually I think it would be safe to remove it completely. Unix platforms should always have stdio, and other platforms should act appropriately. But more below... > Then a first question arises in my head: why isWin32 and not > isWindows? Is there a reason behind that? Wouldn't that prevent > correct behaviour in windows 64 bits? You're right, it should be #isWindows. > My next impression is that testing for "a TTY or a file or a pipe" > seems buggy... We should put a more intention revealing selector like > #isInvalidStdioHandle? > A more high level test will allow us to do any check we want in the > background, and it allows better to understand why we check for TTY or > File or Pipe or la mar en coche :) I made the change so that Damien could test that it gives the behaviour he expects, and did say that the selector will need to be renamed. > What does #stdioHandles return to the image in the case of a > non-console windows VM? I mean, when "it is not possible"? > From the docs, > https://docs.microsoft.com/en-us/windows/console/getstdhandle says we > may have an INVALID_HANDLE_VALUE or NULL in case it fails. > Is the file plugin is masking the error? If so, thats why we need such > strange workarounds... We'd still want the ability to test what type of device stdio is connected to. But I agree the primitive should be doing the correct thing. > - If it is an invalid handle, why not just testing for > "isInvalidHandle" or so? We can have that on the image side and then > dispatch to the correct thing in the file plugin maybe? > - Maybe the #stdioHandles primitive should just fail in the case we > don't have correct handles? that would allow us to do a much more > elegant approach on the image side... I don't think the error handling has been changed in a long time, but just looking quickly at the source code, I think you're correct that it isn't returning the correct values. It should be returning nil for those handles that aren't valid. I don't have my Windows VM handy at the moment, is anyone able to quickly confirm? (Start pharo with Pharo.exe (not PharoConsole.exe) and supply the result from: File stdioHandles I've been asking lots of questions lately and not providing much input (I was hoping to have File Attributes integrated by now, but MacOS file encoding and my inability to get the VM to compile on a Mac VM have frustrated me), so I'm more than happy to tidy up the stdio primitives. I'll need to check that it doesn't break anything on Squeak as well (I don't think any of the changes discussed should cause problems). Cheers, Alistair

Aug. 3, 2018

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

by Guillermo Polito

Hi, I don't know the windows situation at all, but I'm wondering. ([ File stdioDescriptorIsATTY not ] on: PrimitiveFailed do: [ :ex | "HACK kept for retrocompatibility" Smalltalk os isWin32 ]) ifTrue: [ ^ self createStdioFileFor: moniker ]. the first thing I would do, just trying to keep the same behaviour, is to invert the test... Something like Smalltalk os isWin32 ifTrue: [ [ File stdioDescriptorIsATTY not ] on: PrimitiveFailed do: [ :ex | false ]) ifTrue: [ ^ self createStdioFileFor: moniker ]. ] Like that, this would only penalise windows in the worst case. Then a first question arises in my head: why isWin32 and not isWindows? Is there a reason behind that? Wouldn't that prevent correct behaviour in windows 64 bits? My next impression is that testing for "a TTY or a file or a pipe" seems buggy... We should put a more intention revealing selector like #isInvalidStdioHandle? A more high level test will allow us to do any check we want in the background, and it allows better to understand why we check for TTY or File or Pipe or la mar en coche :) On Thu, Aug 2, 2018 at 8:54 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > File class>>stdioHandles calls primitiveFileStdioHandles() which > eventually opens the stdio streams (if possible) using the Windows > native GetStdHandle() function. > What does #stdioHandles return to the image in the case of a non-console windows VM? I mean, when "it is not possible"? >From the docs, https://docs.microsoft.com/en-us/windows/console/getstdhandle says we may have an INVALID_HANDLE_VALUE or NULL in case it fails. Is the file plugin is masking the error? If so, thats why we need such strange workarounds... - If it is an invalid handle, why not just testing for "isInvalidHandle" or so? We can have that on the image side and then dispatch to the correct thing in the file plugin maybe? - Maybe the #stdioHandles primitive should just fail in the case we don't have correct handles? that would allow us to do a much more elegant approach on the image side... > I suspect File needs a nameless variant (I'm not certain how pipes > > work in unix but I doubt echo foo | cat ever touches the filesystem) > > That's my understanding (it doesn't touch the file system). > > Well... I see this is just a aesthetic issue and I don't see how this is related to the above more serious issue...

Aug. 3, 2018

[Pharo 7.0-dev] Build #1157: Fix https://pharo.fogbugz.com/f/cases/22241

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1157 was: SUCCESS. The Pull Request #1627 was integrated: "Fix https://pharo.fogbugz.com/f/cases/22241" Pull request url: https://github.com/pharo-project/pharo/pull/1627 Issue Url: https://pharo.fogbugz.com/f/cases/development Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 3, 2018

[Pharo 7.0-dev] Build #1156: changed the comment

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1156 was: SUCCESS. The Pull Request #1652 was integrated: "changed the comment" Pull request url: https://github.com/pharo-project/pharo/pull/1652 Issue Url: https://pharo.fogbugz.com/f/cases/22144 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 3, 2018

[Pharo 7.0-dev] Build #1155: 20243-Temporary-is-not-detected-as-written-only-when-assigned-in-a-nested-assignment

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1155 was: SUCCESS. The Pull Request #1658 was integrated: "20243-Temporary-is-not-detected-as-written-only-when-assigned-in-a-nested-assignment" Pull request url: https://github.com/pharo-project/pharo/pull/1658 Issue Url: https://pharo.fogbugz.com/f/cases/20243 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 2, 2018

Re: [Pharo-dev] About the infinite debugger

by Norbert Hartl

bump > Am 04.07.2018 um 02:28 schrieb Martin McClure <martin(a)hand2mouse.com>: > >> On 07/03/2018 05:02 PM, Martin McClure wrote: >>> On 06/29/2018 07:48 AM, Guillermo Polito wrote: >>> I know that the exception handling/debugging has been modified several >>> times in the latest years (some refactorings, hiding contexts...), we >>> unfortunately don't have tests for it, so I'd like some more pair of >>> eyes on it. Ben, Martin could you take a look? >>> >> Hi Guille, >> I'm just back from vacation last week, and about to go on vacation for >> another week, but I'll see what I can see. >> About the primitive pragmas for context-marking, I think some of those >> were changed for the exception handling fix that Andres and I did a few >> years back, so *could* be involved in this. I'd hate to see regression >> in the exception handling in an attempt to fix this bug. >> > > After a look at at the pull request, I'm quite sure that removing the > prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring > it! The start of execution of exception handlers must be marked in order > for #findNextHandlerContext to work correctly. If these contexts are not > marked, exceptions signaled from inside an exception handler can find > the wrong handler. See the code and comment in #findNextHandlerContext. > > I'm afraid that I cannot immediately help with the debugger problem, > since I don't know the debugger nearly as well as I do the exception > handling code, and I'm going on vacation for a week in 20 minutes. :-) > Perhaps when I get back I can take a look at it if it is still a problem > by then. > > Regards, > -Martin >

Aug. 2, 2018

Stdio>>#standardIOStreamNamed:forWrite: bug?

by Alistair Grant

Hi Damien, Vincent and Guille, Just a disclaimer: despite having done some work on this, I don't consider myself an expert. If someone else has a better explanation, please jump in. Damien wrote on discord: > is there a notion of standard input/output on windows ? Yes, console applications can use stdio. PharoConsole.exe when run from a command prompt has stdio. (Note that cygwin terminals are different and don't support stdio (since Pharo uses the native windows functions)). > looks like Alistair added the possibility to open files by number, Holger Freyther deserves the credit here. My clumsy git merging left his name out as the author (sorry Holger!). > that's probably what was missing at the time Stdio was introduced I'm not sure that opening files by fd would be useful in this particular case. There are three ways to access files on Windows: file descriptor - posix compatibility FILE* - posix compatibility HANDLE - windows native The VM uses native operations for file i/o on Windows, e.g. Read/WriteConsole() for stdio (including pipe redirection of stdio). Mixing file descriptors and FILE* is possible if you're careful. I don't know how to mix fd / FILE* and HANDLEs. It's probably better to stick with using native windows functions most of the time. We included these functions on Windows since they exist, and there are probably some use cases, but you need to know what you're doing. File class>>stdioHandles calls primitiveFileStdioHandles() which eventually opens the stdio streams (if possible) using the Windows native GetStdHandle() function. > I suspect File needs a nameless variant (I'm not certain how pipes > work in unix but I doubt echo foo | cat ever touches the filesystem) That's my understanding (it doesn't touch the file system). > hmm but the short-term bug is that the TTY logic in Stdio >> > #standardIOStreamNamed:forWrite: fails when all 3 standard streams are > redirected OK, my understanding of what you are saying is that if all 3 io streams are redirected the method incorrectly determines that a console isn't present and so falls back to calling #createStdioFileFor:. More below... > I also don't understand the assumption there Vincent Blondeau added / modified these methods, so he may be able to provide more information. I think the assumption is that if any of the stdio files are connected to a TTY. then it is possible to open all the stdio files. If none are present, then (on Windows) create regular files to act as a substitute. The problem is that it only tests for a TTY, when what we really want is a TTY or a file or a pipe. Assuming I've understood correctly, maybe try modifying (sorry for the loss of formatting, only the last line is changed): File class>>stdioDescriptorIsATTY ^ (0 to: 2) anySatisfy: [ :fdNum | | res | res := self fileDescriptorType: fdNum. res between: 1 and: 3 ] We'd need to rename the method, since it is misleading, but it looks like it better represents the intended use. Cheers, Alistair

Aug. 2, 2018

[Pharo 7.0-dev] Build #1154: 22292-MCTraitDefinition-should-correctly-support-stateful-traits

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1154 was: FAILURE. The Pull Request #1667 was integrated: "22292-MCTraitDefinition-should-correctly-support-stateful-traits" Pull request url: https://github.com/pharo-project/pharo/pull/1667 Issue Url: https://pharo.fogbugz.com/f/cases/22292 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 2, 2018

[Pharo 7.0-dev] Build #1153: 22284-Freeze-during-startup

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1153 was: SUCCESS. The Pull Request #1659 was integrated: "22284-Freeze-during-startup" Pull request url: https://github.com/pharo-project/pharo/pull/1659 Issue Url: https://pharo.fogbugz.com/f/cases/22284 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 1, 2018

[Pharo 7.0-dev] Build #1152: 22291-Deprecation-of-OSEnvironment-default-should-have-a-rewrite-tool

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1152 was: SUCCESS. The Pull Request #1665 was integrated: "22291-Deprecation-of-OSEnvironment-default-should-have-a-rewrite-tool" Pull request url: https://github.com/pharo-project/pharo/pull/1665 Issue Url: https://pharo.fogbugz.com/f/cases/22291 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 1, 2018

Re: [Pharo-dev] Problem with Iceberg and Working Branches

by Eric Gade

Guillermo has found a bug in Iceberg that is slotted to be fixed at the next update, and has provided a temporary workaround. I have to final notes about the "merge" method: 1. After the merge, you must explore the packages and reload any that you've been working on in order to have classes of the correct versions. This was OK for me but might be a problem for people who work on classes all over the place; 2. When committing new changes to your locally merged branch, you will have to sift through every single package and class in the Commit window, since it sees now that just about everything has changed. Again, it helps to know what exactly you've been working on ahead of time. Perhaps a filter on package names (like in Calypso panes) would be a good start? On Wed, Aug 1, 2018 at 9:25 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 1 Aug 2018, at 14:10, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > On Wed, Aug 1, 2018 at 2:02 PM Eric Gade <eric.gade(a)gmail.com> wrote: > >> Every week some tenths of pull requests are integrated in Pharo, so >>> loading the Pharo7 image of today will give you an image compleeetely >>> different from the one you worked with one week ago. >>> >> >> This is something I'm used to from the non-Pharo Git world. Normally I >> would do what it called "rebasing," which essentially replays any commits >> on my branch atop the HEAD of the current master branch. In cases where you >> know that the things you're working on are unlikely to have changed in the >> meantime, this tends to work most of the time. >> > > Well we do not support rebase in iceberg yet. In part because we would > like to keep the UI as simple as possible (because lots of people do not > really know git) and in part because I personally believe rebase as an evil > feature that people tend to overuse. (That does not mean that rebase is bad > in itself, I actually use it myself from time to time, but I'm strongly > against rewriting public commits/history). > > > I support this ^ > > :) > > > >> >> >>> For your particular use case (have a new image and want to keep working >>> on an old pharo branch), I'd suggest that instead of doing "Discard >>> local changes and checkout existing branch" you do >>> >> >> I'll give this a shot in a little bit and let you know if it works. >> > > Cool! > >> >> >>> You have the popup with the "Ignore" and "Debug" options? Could you >>> click on "Debug" and share your stack trace? >>> >> >> No. This is not the normal error popup. It's more like a little dialog >> that only has text and an OK button. However, I was able to go into the >> repository via Iceberg and attempt to checkout the branch from origin >> directly. That did give me a normal error and I do have a fuel dump of the >> stack. Unfortunately it is too big to attach to emails to this list. >> > > If you want, send me a dropbox link or something like that personally... > > >> >> I will send a follow up message with the attachment, but it will need mod >> approval. >> >> On Wed, Aug 1, 2018 at 7:52 AM, Guillermo Polito <guillermopolito@gmail. >> com> wrote: >> >>> Ah, just in case I add to what I say: this particular tricky scenario is >>> specific for Pharo and contributing to Pharo. >>> >>> Any third party project/library will not have the constraints described >>> in my previous email. >>> >>> On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Hi! >>>> >>>> On Wed, Aug 1, 2018 at 1:30 PM Eric Gade <eric.gade(a)gmail.com> wrote: >>>> >>>>> I have already mentioned some of this on Discord so forgive me for >>>>> being redundant if you've seen it. >>>>> >>>>> I'm having problems loading into the latest P7 images from Launcher a >>>>> working branch of Pharo that I have forked. I perform the following steps: >>>>> >>>> >>>> I'll try to reproduce it, but meanwhile. >>>> >>>> >>>>> 1. "Repair" the missing local repository for Pharo and load from my >>>>> forked version on Github >>>>> 2. Now in the "detached working copy" state, I repair again >>>>> 3. This time I select "Discard local changes and checkout existing >>>>> branch". I select my working branch from the remotes >>>>> >>>> >>>> I have a remark on this step, that should be known and understood by >>>> people contributing Pharo. >>>> - When you download an image, that image knows from which commit it was >>>> built. This is done on purpose so then you can continue working from >>>> exactly that commit (less merge problems, do not need to update your live >>>> image...). >>>> - Every week some tenths of pull requests are integrated in Pharo, so >>>> loading the Pharo7 image of today will give you an image compleeetely >>>> different from the one you worked with one week ago. >>>> >>>> What this means, is that if you checkout an old branch, Iceberg will >>>> try to "downgrade" all your packages to your branch's version, and that may >>>> not always work, because while updating pharo packages you may break >>>> running code and running instances (take into account you have several >>>> processes running). This is the same problem of the old "Software update" >>>> option in Pharo that was deprecated and removed some time ago already. And >>>> this is why in general we do not recommend nowadays to update a pharo image >>>> through iceberg, because you cause a kind of self brain-surgery scenario. >>>> >>>> This is why also we DO recommend, when you start with a new image to >>>> "create a new branch from the image commit". Because this option makes you >>>> work on a branch that is 100% in sync with your Pharo image and it will >>>> just simplify your life :). >>>> >>>> For your particular use case (have a new image and want to keep working >>>> on an old pharo branch), I'd suggest that instead of doing "Discard >>>> local changes and checkout existing branch" you do >>>> - load your fork >>>> - create *new* branch from image >>>> - merge your old branch into this new one >>>> >>>> That will be by far less disruptive. >>>> >>>> >>>>> 4. It will attempt to load, but eventually a popup appears (not a >>>>> normal error) that simply says "origin: Error" and "Assertion failed". >>>>> >>>> >>>> You have the popup with the "Ignore" and "Debug" options? Could you >>>> click on "Debug" and share your stack trace? >>>> >>>> >>>>> >>>>> I'm not sure what's going on, since this procedure seemed to work a >>>>> week or so ago if I remember correctly. As of a couple of days ago I can no >>>>> longer load (ie work on) my working branch. >>>>> >>>> >>>> Well, this is for sure related to what I described above, using a new >>>> image with an old branch.... >>>> >>>> >>>>> >>>>> I figure I'm doing something wrong, but need to know what. >>>>> >>>> >>>> Maybe not, and it's just a matter of a complex scenario + an unexpected >>>> case in iceberg (thus the assertion). >>>> >>>> Keep us updated to see if we can help you, >>>> Guille >>>> >>> >>> >>> -- >>> >>> 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 >>> >> >> >> >> -- >> Eric >> > > > -- > > 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 > > > -- Eric

Aug. 1, 2018

[Pharo 7.0-dev] Build #1151: 22289-Pharo-bootstrap-stopped-to-be-repository-agnostic

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1151 was: SUCCESS. The Pull Request #1664 was integrated: "22289-Pharo-bootstrap-stopped-to-be-repository-agnostic" Pull request url: https://github.com/pharo-project/pharo/pull/1664 Issue Url: https://pharo.fogbugz.com/f/cases/22289 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 1, 2018

Re: [Pharo-dev] Problem with Iceberg and Working Branches

by Esteban Lorenzano

> On 1 Aug 2018, at 14:10, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Wed, Aug 1, 2018 at 2:02 PM Eric Gade <eric.gade(a)gmail.com <mailto:eric.gade@gmail.com>> wrote: > Every week some tenths of pull requests are integrated in Pharo, so loading the Pharo7 image of today will give you an image compleeetely different from the one you worked with one week ago. > > This is something I'm used to from the non-Pharo Git world. Normally I would do what it called "rebasing," which essentially replays any commits on my branch atop the HEAD of the current master branch. In cases where you know that the things you're working on are unlikely to have changed in the meantime, this tends to work most of the time. > > Well we do not support rebase in iceberg yet. In part because we would like to keep the UI as simple as possible (because lots of people do not really know git) and in part because I personally believe rebase as an evil feature that people tend to overuse. (That does not mean that rebase is bad in itself, I actually use it myself from time to time, but I'm strongly against rewriting public commits/history). I support this ^ :) > > > For your particular use case (have a new image and want to keep working on an old pharo branch), I'd suggest that instead of doing "Discard local changes and checkout existing branch" you do > > I'll give this a shot in a little bit and let you know if it works. > > Cool! > > > You have the popup with the "Ignore" and "Debug" options? Could you click on "Debug" and share your stack trace? > > No. This is not the normal error popup. It's more like a little dialog that only has text and an OK button. However, I was able to go into the repository via Iceberg and attempt to checkout the branch from origin directly. That did give me a normal error and I do have a fuel dump of the stack. Unfortunately it is too big to attach to emails to this list. > > If you want, send me a dropbox link or something like that personally... > > > I will send a follow up message with the attachment, but it will need mod approval. > > On Wed, Aug 1, 2018 at 7:52 AM, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Ah, just in case I add to what I say: this particular tricky scenario is specific for Pharo and contributing to Pharo. > > Any third party project/library will not have the constraints described in my previous email. > > On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Hi! > > On Wed, Aug 1, 2018 at 1:30 PM Eric Gade <eric.gade(a)gmail.com <mailto:eric.gade@gmail.com>> wrote: > I have already mentioned some of this on Discord so forgive me for being redundant if you've seen it. > > I'm having problems loading into the latest P7 images from Launcher a working branch of Pharo that I have forked. I perform the following steps: > > I'll try to reproduce it, but meanwhile. > > 1. "Repair" the missing local repository for Pharo and load from my forked version on Github > 2. Now in the "detached working copy" state, I repair again > 3. This time I select "Discard local changes and checkout existing branch". I select my working branch from the remotes > > I have a remark on this step, that should be known and understood by people contributing Pharo. > - When you download an image, that image knows from which commit it was built. This is done on purpose so then you can continue working from exactly that commit (less merge problems, do not need to update your live image...). > - Every week some tenths of pull requests are integrated in Pharo, so loading the Pharo7 image of today will give you an image compleeetely different from the one you worked with one week ago. > > What this means, is that if you checkout an old branch, Iceberg will try to "downgrade" all your packages to your branch's version, and that may not always work, because while updating pharo packages you may break running code and running instances (take into account you have several processes running). This is the same problem of the old "Software update" option in Pharo that was deprecated and removed some time ago already. And this is why in general we do not recommend nowadays to update a pharo image through iceberg, because you cause a kind of self brain-surgery scenario. > > This is why also we DO recommend, when you start with a new image to "create a new branch from the image commit". Because this option makes you work on a branch that is 100% in sync with your Pharo image and it will just simplify your life :). > > For your particular use case (have a new image and want to keep working on an old pharo branch), I'd suggest that instead of doing "Discard local changes and checkout existing branch" you do > - load your fork > - create *new* branch from image > - merge your old branch into this new one > > That will be by far less disruptive. > > 4. It will attempt to load, but eventually a popup appears (not a normal error) that simply says "origin: Error" and "Assertion failed". > > You have the popup with the "Ignore" and "Debug" options? Could you click on "Debug" and share your stack trace? > > > I'm not sure what's going on, since this procedure seemed to work a week or so ago if I remember correctly. As of a couple of days ago I can no longer load (ie work on) my working branch. > > Well, this is for sure related to what I described above, using a new image with an old branch.... > > > I figure I'm doing something wrong, but need to know what. > > Maybe not, and it's just a matter of a complex scenario + an unexpected case in iceberg (thus the assertion). > > Keep us updated to see if we can help you, > Guille > > > -- > > 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 > > > > -- > Eric > > > -- > > 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

Aug. 1, 2018

Re: [Pharo-dev] Problem with Iceberg and Working Branches

by Guillermo Polito

On Wed, Aug 1, 2018 at 2:02 PM Eric Gade <eric.gade(a)gmail.com> wrote: > Every week some tenths of pull requests are integrated in Pharo, so >> loading the Pharo7 image of today will give you an image compleeetely >> different from the one you worked with one week ago. >> > > This is something I'm used to from the non-Pharo Git world. Normally I > would do what it called "rebasing," which essentially replays any commits > on my branch atop the HEAD of the current master branch. In cases where you > know that the things you're working on are unlikely to have changed in the > meantime, this tends to work most of the time. > Well we do not support rebase in iceberg yet. In part because we would like to keep the UI as simple as possible (because lots of people do not really know git) and in part because I personally believe rebase as an evil feature that people tend to overuse. (That does not mean that rebase is bad in itself, I actually use it myself from time to time, but I'm strongly against rewriting public commits/history). > > >> For your particular use case (have a new image and want to keep working >> on an old pharo branch), I'd suggest that instead of doing "Discard >> local changes and checkout existing branch" you do >> > > I'll give this a shot in a little bit and let you know if it works. > Cool! > > >> You have the popup with the "Ignore" and "Debug" options? Could you click >> on "Debug" and share your stack trace? >> > > No. This is not the normal error popup. It's more like a little dialog > that only has text and an OK button. However, I was able to go into the > repository via Iceberg and attempt to checkout the branch from origin > directly. That did give me a normal error and I do have a fuel dump of the > stack. Unfortunately it is too big to attach to emails to this list. > If you want, send me a dropbox link or something like that personally... > > I will send a follow up message with the attachment, but it will need mod > approval. > > On Wed, Aug 1, 2018 at 7:52 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Ah, just in case I add to what I say: this particular tricky scenario is >> specific for Pharo and contributing to Pharo. >> >> Any third party project/library will not have the constraints described >> in my previous email. >> >> On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Hi! >>> >>> On Wed, Aug 1, 2018 at 1:30 PM Eric Gade <eric.gade(a)gmail.com> wrote: >>> >>>> I have already mentioned some of this on Discord so forgive me for >>>> being redundant if you've seen it. >>>> >>>> I'm having problems loading into the latest P7 images from Launcher a >>>> working branch of Pharo that I have forked. I perform the following steps: >>>> >>> >>> I'll try to reproduce it, but meanwhile. >>> >>> >>>> 1. "Repair" the missing local repository for Pharo and load from my >>>> forked version on Github >>>> 2. Now in the "detached working copy" state, I repair again >>>> 3. This time I select "Discard local changes and checkout existing >>>> branch". I select my working branch from the remotes >>>> >>> >>> I have a remark on this step, that should be known and understood by >>> people contributing Pharo. >>> - When you download an image, that image knows from which commit it was >>> built. This is done on purpose so then you can continue working from >>> exactly that commit (less merge problems, do not need to update your live >>> image...). >>> - Every week some tenths of pull requests are integrated in Pharo, so >>> loading the Pharo7 image of today will give you an image compleeetely >>> different from the one you worked with one week ago. >>> >>> What this means, is that if you checkout an old branch, Iceberg will try >>> to "downgrade" all your packages to your branch's version, and that may not >>> always work, because while updating pharo packages you may break running >>> code and running instances (take into account you have several processes >>> running). This is the same problem of the old "Software update" option in >>> Pharo that was deprecated and removed some time ago already. And this is >>> why in general we do not recommend nowadays to update a pharo image through >>> iceberg, because you cause a kind of self brain-surgery scenario. >>> >>> This is why also we DO recommend, when you start with a new image to >>> "create a new branch from the image commit". Because this option makes you >>> work on a branch that is 100% in sync with your Pharo image and it will >>> just simplify your life :). >>> >>> For your particular use case (have a new image and want to keep working >>> on an old pharo branch), I'd suggest that instead of doing "Discard >>> local changes and checkout existing branch" you do >>> - load your fork >>> - create *new* branch from image >>> - merge your old branch into this new one >>> >>> That will be by far less disruptive. >>> >>> >>>> 4. It will attempt to load, but eventually a popup appears (not a >>>> normal error) that simply says "origin: Error" and "Assertion failed". >>>> >>> >>> You have the popup with the "Ignore" and "Debug" options? Could you >>> click on "Debug" and share your stack trace? >>> >>> >>>> >>>> I'm not sure what's going on, since this procedure seemed to work a >>>> week or so ago if I remember correctly. As of a couple of days ago I can no >>>> longer load (ie work on) my working branch. >>>> >>> >>> Well, this is for sure related to what I described above, using a new >>> image with an old branch.... >>> >>> >>>> >>>> I figure I'm doing something wrong, but need to know what. >>>> >>> >>> Maybe not, and it's just a matter of a complex scenario + an unexpected >>> case in iceberg (thus the assertion). >>> >>> Keep us updated to see if we can help you, >>> Guille >>> >> >> >> -- >> >> >> >> 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 >> > > > > -- > Eric > -- 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

Aug. 1, 2018

Re: [Pharo-dev] Problem with Iceberg and Working Branches

by Eric Gade

Ok, so when I follow these steps: - load your fork - create *new* branch from image - merge your old branch into this new one I get the same kind of error I was reporting above. While the previous email with the Fuel dump awaits mod approval, I'll just attach this screenshot so you can see what I mean On Wed, Aug 1, 2018 at 8:02 AM, Eric Gade <eric.gade(a)gmail.com> wrote: > Here is the fuel dump of the stack (attached) > > On Wed, Aug 1, 2018 at 8:01 AM, Eric Gade <eric.gade(a)gmail.com> wrote: > >> Every week some tenths of pull requests are integrated in Pharo, so >>> loading the Pharo7 image of today will give you an image compleeetely >>> different from the one you worked with one week ago. >>> >> >> This is something I'm used to from the non-Pharo Git world. Normally I >> would do what it called "rebasing," which essentially replays any commits >> on my branch atop the HEAD of the current master branch. In cases where you >> know that the things you're working on are unlikely to have changed in the >> meantime, this tends to work most of the time. >> >> >>> For your particular use case (have a new image and want to keep working >>> on an old pharo branch), I'd suggest that instead of doing "Discard >>> local changes and checkout existing branch" you do >>> >> >> I'll give this a shot in a little bit and let you know if it works. >> >> >>> You have the popup with the "Ignore" and "Debug" options? Could you >>> click on "Debug" and share your stack trace? >>> >> >> No. This is not the normal error popup. It's more like a little dialog >> that only has text and an OK button. However, I was able to go into the >> repository via Iceberg and attempt to checkout the branch from origin >> directly. That did give me a normal error and I do have a fuel dump of the >> stack. Unfortunately it is too big to attach to emails to this list. >> >> I will send a follow up message with the attachment, but it will need mod >> approval. >> >> On Wed, Aug 1, 2018 at 7:52 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Ah, just in case I add to what I say: this particular tricky scenario is >>> specific for Pharo and contributing to Pharo. >>> >>> Any third party project/library will not have the constraints described >>> in my previous email. >>> >>> On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Hi! >>>> >>>> On Wed, Aug 1, 2018 at 1:30 PM Eric Gade <eric.gade(a)gmail.com> wrote: >>>> >>>>> I have already mentioned some of this on Discord so forgive me for >>>>> being redundant if you've seen it. >>>>> >>>>> I'm having problems loading into the latest P7 images from Launcher a >>>>> working branch of Pharo that I have forked. I perform the following steps: >>>>> >>>> >>>> I'll try to reproduce it, but meanwhile. >>>> >>>> >>>>> 1. "Repair" the missing local repository for Pharo and load from my >>>>> forked version on Github >>>>> 2. Now in the "detached working copy" state, I repair again >>>>> 3. This time I select "Discard local changes and checkout existing >>>>> branch". I select my working branch from the remotes >>>>> >>>> >>>> I have a remark on this step, that should be known and understood by >>>> people contributing Pharo. >>>> - When you download an image, that image knows from which commit it was >>>> built. This is done on purpose so then you can continue working from >>>> exactly that commit (less merge problems, do not need to update your live >>>> image...). >>>> - Every week some tenths of pull requests are integrated in Pharo, so >>>> loading the Pharo7 image of today will give you an image compleeetely >>>> different from the one you worked with one week ago. >>>> >>>> What this means, is that if you checkout an old branch, Iceberg will >>>> try to "downgrade" all your packages to your branch's version, and that may >>>> not always work, because while updating pharo packages you may break >>>> running code and running instances (take into account you have several >>>> processes running). This is the same problem of the old "Software update" >>>> option in Pharo that was deprecated and removed some time ago already. And >>>> this is why in general we do not recommend nowadays to update a pharo image >>>> through iceberg, because you cause a kind of self brain-surgery scenario. >>>> >>>> This is why also we DO recommend, when you start with a new image to >>>> "create a new branch from the image commit". Because this option makes you >>>> work on a branch that is 100% in sync with your Pharo image and it will >>>> just simplify your life :). >>>> >>>> For your particular use case (have a new image and want to keep working >>>> on an old pharo branch), I'd suggest that instead of doing "Discard >>>> local changes and checkout existing branch" you do >>>> - load your fork >>>> - create *new* branch from image >>>> - merge your old branch into this new one >>>> >>>> That will be by far less disruptive. >>>> >>>> >>>>> 4. It will attempt to load, but eventually a popup appears (not a >>>>> normal error) that simply says "origin: Error" and "Assertion failed". >>>>> >>>> >>>> You have the popup with the "Ignore" and "Debug" options? Could you >>>> click on "Debug" and share your stack trace? >>>> >>>> >>>>> >>>>> I'm not sure what's going on, since this procedure seemed to work a >>>>> week or so ago if I remember correctly. As of a couple of days ago I can no >>>>> longer load (ie work on) my working branch. >>>>> >>>> >>>> Well, this is for sure related to what I described above, using a new >>>> image with an old branch.... >>>> >>>> >>>>> >>>>> I figure I'm doing something wrong, but need to know what. >>>>> >>>> >>>> Maybe not, and it's just a matter of a complex scenario + an unexpected >>>> case in iceberg (thus the assertion). >>>> >>>> Keep us updated to see if we can help you, >>>> Guille >>>> >>> >>> >>> -- >>> >>> >>> >>> 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 >>> >> >> >> >> -- >> Eric >> > > > > -- > Eric > -- Eric

Aug. 1, 2018

Re: [Pharo-dev] Problem with Iceberg and Working Branches

by Eric Gade

> > Every week some tenths of pull requests are integrated in Pharo, so > loading the Pharo7 image of today will give you an image compleeetely > different from the one you worked with one week ago. > This is something I'm used to from the non-Pharo Git world. Normally I would do what it called "rebasing," which essentially replays any commits on my branch atop the HEAD of the current master branch. In cases where you know that the things you're working on are unlikely to have changed in the meantime, this tends to work most of the time. > For your particular use case (have a new image and want to keep working on > an old pharo branch), I'd suggest that instead of doing "Discard local > changes and checkout existing branch" you do > I'll give this a shot in a little bit and let you know if it works. > You have the popup with the "Ignore" and "Debug" options? Could you click > on "Debug" and share your stack trace? > No. This is not the normal error popup. It's more like a little dialog that only has text and an OK button. However, I was able to go into the repository via Iceberg and attempt to checkout the branch from origin directly. That did give me a normal error and I do have a fuel dump of the stack. Unfortunately it is too big to attach to emails to this list. I will send a follow up message with the attachment, but it will need mod approval. On Wed, Aug 1, 2018 at 7:52 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ah, just in case I add to what I say: this particular tricky scenario is > specific for Pharo and contributing to Pharo. > > Any third party project/library will not have the constraints described in > my previous email. > > On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi! >> >> On Wed, Aug 1, 2018 at 1:30 PM Eric Gade <eric.gade(a)gmail.com> wrote: >> >>> I have already mentioned some of this on Discord so forgive me for being >>> redundant if you've seen it. >>> >>> I'm having problems loading into the latest P7 images from Launcher a >>> working branch of Pharo that I have forked. I perform the following steps: >>> >> >> I'll try to reproduce it, but meanwhile. >> >> >>> 1. "Repair" the missing local repository for Pharo and load from my >>> forked version on Github >>> 2. Now in the "detached working copy" state, I repair again >>> 3. This time I select "Discard local changes and checkout existing >>> branch". I select my working branch from the remotes >>> >> >> I have a remark on this step, that should be known and understood by >> people contributing Pharo. >> - When you download an image, that image knows from which commit it was >> built. This is done on purpose so then you can continue working from >> exactly that commit (less merge problems, do not need to update your live >> image...). >> - Every week some tenths of pull requests are integrated in Pharo, so >> loading the Pharo7 image of today will give you an image compleeetely >> different from the one you worked with one week ago. >> >> What this means, is that if you checkout an old branch, Iceberg will try >> to "downgrade" all your packages to your branch's version, and that may not >> always work, because while updating pharo packages you may break running >> code and running instances (take into account you have several processes >> running). This is the same problem of the old "Software update" option in >> Pharo that was deprecated and removed some time ago already. And this is >> why in general we do not recommend nowadays to update a pharo image through >> iceberg, because you cause a kind of self brain-surgery scenario. >> >> This is why also we DO recommend, when you start with a new image to >> "create a new branch from the image commit". Because this option makes you >> work on a branch that is 100% in sync with your Pharo image and it will >> just simplify your life :). >> >> For your particular use case (have a new image and want to keep working >> on an old pharo branch), I'd suggest that instead of doing "Discard >> local changes and checkout existing branch" you do >> - load your fork >> - create *new* branch from image >> - merge your old branch into this new one >> >> That will be by far less disruptive. >> >> >>> 4. It will attempt to load, but eventually a popup appears (not a normal >>> error) that simply says "origin: Error" and "Assertion failed". >>> >> >> You have the popup with the "Ignore" and "Debug" options? Could you click >> on "Debug" and share your stack trace? >> >> >>> >>> I'm not sure what's going on, since this procedure seemed to work a week >>> or so ago if I remember correctly. As of a couple of days ago I can no >>> longer load (ie work on) my working branch. >>> >> >> Well, this is for sure related to what I described above, using a new >> image with an old branch.... >> >> >>> >>> I figure I'm doing something wrong, but need to know what. >>> >> >> Maybe not, and it's just a matter of a complex scenario + an unexpected >> case in iceberg (thus the assertion). >> >> Keep us updated to see if we can help you, >> Guille >> > > > -- > > > > 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 > -- Eric

Aug. 1, 2018

Re: [Pharo-dev] Problem with Iceberg and Working Branches

by Guillermo Polito

Ah, just in case I add to what I say: this particular tricky scenario is specific for Pharo and contributing to Pharo. Any third party project/library will not have the constraints described in my previous email. On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi! > > On Wed, Aug 1, 2018 at 1:30 PM Eric Gade <eric.gade(a)gmail.com> wrote: > >> I have already mentioned some of this on Discord so forgive me for being >> redundant if you've seen it. >> >> I'm having problems loading into the latest P7 images from Launcher a >> working branch of Pharo that I have forked. I perform the following steps: >> > > I'll try to reproduce it, but meanwhile. > > >> 1. "Repair" the missing local repository for Pharo and load from my >> forked version on Github >> 2. Now in the "detached working copy" state, I repair again >> 3. This time I select "Discard local changes and checkout existing >> branch". I select my working branch from the remotes >> > > I have a remark on this step, that should be known and understood by > people contributing Pharo. > - When you download an image, that image knows from which commit it was > built. This is done on purpose so then you can continue working from > exactly that commit (less merge problems, do not need to update your live > image...). > - Every week some tenths of pull requests are integrated in Pharo, so > loading the Pharo7 image of today will give you an image compleeetely > different from the one you worked with one week ago. > > What this means, is that if you checkout an old branch, Iceberg will try > to "downgrade" all your packages to your branch's version, and that may not > always work, because while updating pharo packages you may break running > code and running instances (take into account you have several processes > running). This is the same problem of the old "Software update" option in > Pharo that was deprecated and removed some time ago already. And this is > why in general we do not recommend nowadays to update a pharo image through > iceberg, because you cause a kind of self brain-surgery scenario. > > This is why also we DO recommend, when you start with a new image to > "create a new branch from the image commit". Because this option makes you > work on a branch that is 100% in sync with your Pharo image and it will > just simplify your life :). > > For your particular use case (have a new image and want to keep working on > an old pharo branch), I'd suggest that instead of doing "Discard local > changes and checkout existing branch" you do > - load your fork > - create *new* branch from image > - merge your old branch into this new one > > That will be by far less disruptive. > > >> 4. It will attempt to load, but eventually a popup appears (not a normal >> error) that simply says "origin: Error" and "Assertion failed". >> > > You have the popup with the "Ignore" and "Debug" options? Could you click > on "Debug" and share your stack trace? > > >> >> I'm not sure what's going on, since this procedure seemed to work a week >> or so ago if I remember correctly. As of a couple of days ago I can no >> longer load (ie work on) my working branch. >> > > Well, this is for sure related to what I described above, using a new > image with an old branch.... > > >> >> I figure I'm doing something wrong, but need to know what. >> > > Maybe not, and it's just a matter of a complex scenario + an unexpected > case in iceberg (thus the assertion). > > Keep us updated to see if we can help you, > Guille > -- 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

Aug. 1, 2018

Re: [Pharo-dev] Problem with Iceberg and Working Branches

by Guillermo Polito

Hi! On Wed, Aug 1, 2018 at 1:30 PM Eric Gade <eric.gade(a)gmail.com> wrote: > I have already mentioned some of this on Discord so forgive me for being > redundant if you've seen it. > > I'm having problems loading into the latest P7 images from Launcher a > working branch of Pharo that I have forked. I perform the following steps: > I'll try to reproduce it, but meanwhile. > 1. "Repair" the missing local repository for Pharo and load from my forked > version on Github > 2. Now in the "detached working copy" state, I repair again > 3. This time I select "Discard local changes and checkout existing > branch". I select my working branch from the remotes > I have a remark on this step, that should be known and understood by people contributing Pharo. - When you download an image, that image knows from which commit it was built. This is done on purpose so then you can continue working from exactly that commit (less merge problems, do not need to update your live image...). - Every week some tenths of pull requests are integrated in Pharo, so loading the Pharo7 image of today will give you an image compleeetely different from the one you worked with one week ago. What this means, is that if you checkout an old branch, Iceberg will try to "downgrade" all your packages to your branch's version, and that may not always work, because while updating pharo packages you may break running code and running instances (take into account you have several processes running). This is the same problem of the old "Software update" option in Pharo that was deprecated and removed some time ago already. And this is why in general we do not recommend nowadays to update a pharo image through iceberg, because you cause a kind of self brain-surgery scenario. This is why also we DO recommend, when you start with a new image to "create a new branch from the image commit". Because this option makes you work on a branch that is 100% in sync with your Pharo image and it will just simplify your life :). For your particular use case (have a new image and want to keep working on an old pharo branch), I'd suggest that instead of doing "Discard local changes and checkout existing branch" you do - load your fork - create *new* branch from image - merge your old branch into this new one That will be by far less disruptive. > 4. It will attempt to load, but eventually a popup appears (not a normal > error) that simply says "origin: Error" and "Assertion failed". > You have the popup with the "Ignore" and "Debug" options? Could you click on "Debug" and share your stack trace? > > I'm not sure what's going on, since this procedure seemed to work a week > or so ago if I remember correctly. As of a couple of days ago I can no > longer load (ie work on) my working branch. > Well, this is for sure related to what I described above, using a new image with an old branch.... > > I figure I'm doing something wrong, but need to know what. > Maybe not, and it's just a matter of a complex scenario + an unexpected case in iceberg (thus the assertion). Keep us updated to see if we can help you, Guille

Aug. 1, 2018

[Pharo 7.0-dev] Build #1150: 21852-Should-add-a-nice-comment-to-FileStream-to-help-migration

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1150 was: SUCCESS. The Pull Request #1654 was integrated: "21852-Should-add-a-nice-comment-to-FileStream-to-help-migration" Pull request url: https://github.com/pharo-project/pharo/pull/1654 Issue Url: https://pharo.fogbugz.com/f/cases/21852 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 1, 2018

Problem with Iceberg and Working Branches

by Eric Gade

I have already mentioned some of this on Discord so forgive me for being redundant if you've seen it. I'm having problems loading into the latest P7 images from Launcher a working branch of Pharo that I have forked. I perform the following steps: 1. "Repair" the missing local repository for Pharo and load from my forked version on Github 2. Now in the "detached working copy" state, I repair again 3. This time I select "Discard local changes and checkout existing branch". I select my working branch from the remotes 4. It will attempt to load, but eventually a popup appears (not a normal error) that simply says "origin: Error" and "Assertion failed". I'm not sure what's going on, since this procedure seemed to work a week or so ago if I remember correctly. As of a couple of days ago I can no longer load (ie work on) my working branch. I figure I'm doing something wrong, but need to know what. -- Eric

Aug. 1, 2018

[Pharo 7.0-dev] Build #1149: 22288-The-changes-in-21855-affect-old-extension-methods-that-are-not-case-equals

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1149 was: SUCCESS. The Pull Request #1663 was integrated: "22288-The-changes-in-21855-affect-old-extension-methods-that-are-not-case-equals" Pull request url: https://github.com/pharo-project/pharo/pull/1663 Issue Url: https://pharo.fogbugz.com/f/cases/22288 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 1, 2018

Re: [Pharo-dev] CI Issue on PR

by Guillermo Polito

Just FYI, Pablo has answered in the PR. In short, adding new packages means adding them also in the baselines, otherwise metacello does not load them. On Wed, Aug 1, 2018 at 6:48 AM Eric Gade <eric.gade(a)gmail.com> wrote: > Hello all, > > I'm having a strange issue with CI on my recent pull request. See > https://github.com/pharo-project/pharo/pull/1666#issuecomment-409431721 > > The short if it is that tests are failing because it seems some of the new > classes I created are not being loaded into whatever CI is doing. Those > classes are clearly in the commits however. Not sure how to handle this. > It's entirely possible I messed up a part of this process. > > Any suggestions? > > -- > Eric > -- 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

Aug. 1, 2018

[Pharo 7.0-dev] Build #1148: 22287-size-t-type-does-not-have-right-size-in-windows-64bit

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1148 was: SUCCESS. The Pull Request #1660 was integrated: "22287-size-t-type-does-not-have-right-size-in-windows-64bit" Pull request url: https://github.com/pharo-project/pharo/pull/1660 Issue Url: https://pharo.fogbugz.com/f/cases/22287 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 1, 2018