- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] can not compile pharo-vm on linux

by Nicolai Hess

2014-09-23 14:11 GMT+02:00 Damien Cassou <damien.cassou(a)gmail.com>: > On Mon, Sep 22, 2014 at 11:10 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > Did anything changed in the pharovm-linux-build-setup ? > > > if you want a clean system where the pharo VM depends on libraries on > your system and not on things downloaded at compile time, you can use > these sources: http://files.pharo.org/vm/src/vm-unix-sources/blessed. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > Ah this one works (changing some paths in directories.cmake). How it comes, this one does not have the libgit2 and libssh2 as dependencies entries in the CMakeLists.txt file? My CMakeLists.txt has these entries: add_subdirectory("thirdParty/libssh2") set(libssh2_LIB "${externalModulesDir}/libssh2.so.1.0.1") add_library("${libssh2_LIB}" SHARED IMPORTED GLOBAL) set_target_properties("${libssh2_LIB}" PROPERTIES IMPORTED_LOCATION "${libssh2_LIB}") add_dependencies("${libssh2_LIB}" "libssh2") add_dependencies(pharo libssh2) add_subdirectory("thirdParty/libgit2") set(libgit2_LIB "${externalModulesDir}/libgit2.so.0.20.0") add_library("${libgit2_LIB}" SHARED IMPORTED GLOBAL) set_target_properties("${libgit2_LIB}" PROPERTIES IMPORTED_LOCATION "${libgit2_LIB}") add_dependencies("${libgit2_LIB}" "libgit2") add_dependencies(pharo libgit2) by the way this pharovmbuild buildUnix32 has changed ( https://github.com/pharo-project/pharo-vm/commit/d0ce32de77f16a67b8df13a3ab… ) I think my last successful linux build was 6 month ago :) But I don't see why it does not work on my machine whereas it seems to work on the build slave.

Sept. 23, 2014

Re: [Pharo-dev] Code critics problem

by Nicolai Hess

The same as this one 13874 <https://pharo.fogbugz.com/default.asp?13874> MNU: PackageTreePackageSelection>>packageName (about the fuel-file, how do you work with that, I tried to read it in pharo but it does not work) 2014-09-23 19:39 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Hello, > > I tried to run Code Critics on some packages and I got a stacktrace. > > I fueled it out: > > > https://www.dropbox.com/s/m4plmq5lilyvixl/Debugger-Stack-UndefinedObject-20… > > Ideas why? > > Are code critics working in the first place? > > TIA > Phil >

Sept. 23, 2014

Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil

by Max Leske

Just for reference, in my case I can reproduce it only because I trick the simulation into thinking that the process Iâm working with is not the active process. Hereâs a test case that reproduces the problem (the process context will be in the handler at the end): testIsTerminatingForcedTermination | process started unwound terminator | process := [ started := true. [ process terminate ] ensure: [ terminator := Processor activeProcess. unwound := true ] ] newProcess. "Because we're simulating, we need to trick the simulation to get into the code for not running processes." [ process suspendedContext selector = #isActiveProcess ] whileFalse: [ process step ]. process popTo: process suspendedContext sender value: false. "Again, trick the simulation into thinking the process is suspended." [ process suspendedContext selector = #popTo: ] whileFalse: [ process step ]. [ process suspendedContext selector = #activeProcess ] whileFalse: [ process step ]. process popTo: process suspendedContext sender value: false. process completeTo: process suspendedContext bottomContext On 23.09.2014, at 19:53, Martin McClure <martin(a)hand2mouse.com> wrote: > On 09/23/2014 08:48 AM, ClÃ©ment Bera wrote: >> The theory I've had for a while for this issue is that ensure blocks are >> sometimes not executed when the process is manipulated / terminated from >> another process (so topContext was not assigned even if in an ensure >> block). I've tried to fix it but I failed. > > VW had a long-standing bug (finally fixed some time ago) that when a > process was terminated, any unwind blocks that had already started would > not finish. This caused us all kinds of grief -- most commonly stuck > semaphores due to #critical: blocks not signaling the semaphore. > > I haven't had time to look into whether Pharo has the same problem, but > in my reading through the Exceptions chapter of "Deep into Pharo" it > looked like that problem was probably in Pharo, too. > > I believe that the "correct" (most desirable) behavior for unwind blocks > when the process is terminated is that > > 1) Any unwind blocks that are on the stack but have not yet started > evaluation should be run, in order, before the process finally terminates. > > 2) Any unwind blocks that are in the process of being evaluated should > be allowed to finish before proceeding with step 1. > > 3) Any unwind block that, at any point in its evaluation, signals an > exception, should have a handler for that exception in some context > within its own evaluation. Any unwind block that signals an exception > which it does not handle has given up the right to its own normal > completion, and process termination is free to skip the rest of that > unwind block. > > Behavior 1) I believe we already do. We probably also do 3), more or > less. I have my doubts about 2). > > Regards, > > -Martin >

Sept. 23, 2014

Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil

by Martin McClure

On 09/23/2014 08:48 AM, ClÃ©ment Bera wrote: > The theory I've had for a while for this issue is that ensure blocks are > sometimes not executed when the process is manipulated / terminated from > another process (so topContext was not assigned even if in an ensure > block). I've tried to fix it but I failed. VW had a long-standing bug (finally fixed some time ago) that when a process was terminated, any unwind blocks that had already started would not finish. This caused us all kinds of grief -- most commonly stuck semaphores due to #critical: blocks not signaling the semaphore. I haven't had time to look into whether Pharo has the same problem, but in my reading through the Exceptions chapter of "Deep into Pharo" it looked like that problem was probably in Pharo, too. I believe that the "correct" (most desirable) behavior for unwind blocks when the process is terminated is that 1) Any unwind blocks that are on the stack but have not yet started evaluation should be run, in order, before the process finally terminates. 2) Any unwind blocks that are in the process of being evaluated should be allowed to finish before proceeding with step 1. 3) Any unwind block that, at any point in its evaluation, signals an exception, should have a handler for that exception in some context within its own evaluation. Any unwind block that signals an exception which it does not handle has given up the right to its own normal completion, and process termination is free to skip the rest of that unwind block. Behavior 1) I believe we already do. We probably also do 3), more or less. I have my doubts about 2). Regards, -Martin

Sept. 23, 2014

Code critics problem

by phil＠highoctane.be

Hello, I tried to run Code Critics on some packages and I got a stacktrace. I fueled it out: https://www.dropbox.com/s/m4plmq5lilyvixl/Debugger-Stack-UndefinedObject-20… Ideas why? Are code critics working in the first place? TIA Phil

Sept. 23, 2014

Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil

by Clara Allende

https://pharo.fogbugz.com/f/cases/14060/MNU-receiver-of-stepToCallee-is-nil 2014-09-23 17:48 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > The theory I've had for a while for this issue is that ensure blocks are > sometimes not executed when the process is manipulated / terminated from > another process (so topContext was not assigned even if in an ensure > block). I've tried to fix it but I failed. > > Can you give a reproduceable case ? And open a bug tracker issue with it ? > > Thanks. > > > > 2014-09-23 16:45 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: > >> Sorry, the message is #stepToCallee (without the colon, my bad). >> in 40243 I still get it. >> >> >> >> >> 2014-09-23 16:30 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: >> >>> pharo 4, but not the latest image >>> >>> 2014-09-23 16:27 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>> >>>> In the latest Pharo 4, #stepToCallee: is not implemented nor sent. >>>> >>>> Which version of Pharo are you using ? >>>> >>>> >>>> 2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: >>>> >>>>> Hi! >>>>> When debugging tests, if I just close the debugger without finishing >>>>> the test run, I get this weird message. Has anybody had this problem >>>>> before? >>>>> >>>> >>>> >>> >> >

Sept. 23, 2014

Re: [Pharo-dev] gitfiletree on Windows

by kilon alios

Definitely interested, but no promises. I lousy at understanding other's people code. Will give it a read and see if I can understand its mechanics. On Tue, Sep 23, 2014 at 4:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > is already on the way. > if someone wants to collaborate, here is the project: > > https://github.com/theseion/LibGit > > Max is owner for now, but is a community effort :) > He can answer better than me what is missing. > > Esteban > > On 23 Sep 2014, at 15:14, kilon alios <kilon.alios(a)gmail.com> wrote: > > how about libgit2 ? --> https://libgit2.github.com/ > > Seems doable via Nativeboost and probably gives more power than the > terminal. > > On Tue, Sep 23, 2014 at 4:00 PM, Sebastian Sastre < > sebastian(a)flowingconcept.com> wrote: > >> yeah I don't even want to commit there just clone a repo so an image can >> be built there >> >> I guess I'm asking for too much >> >> from iPad >> >> On 23/09/2014, at 09:49, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >> My short answer: despite trying for quite I while, I never succeeded and >> moved to FileTree only. >> >> Now, you can have a Windows VM under OS X where you share folders and >> images. >> >> Work wherever, run in Windows, commit on OSX. >> >> Frankenimages :-) >> >> Phil >> >> On Tue, Sep 23, 2014 at 2:31 PM, Sebastian Sastre < >> sebastian(a)flowingconcept.com> wrote: >> >>> I'm taking a look at making gitfiletree in Windows and OSWindows seems >>> to be helpful since OSProcess is no good for getting PipeableOSProcess >>> executed in Windows. >>> >>> On the other hand, unless I'm missing something, there is no pipeable >>> process in Windows so the whole strategy on how gitfiletree makes one >>> command after the other changes (see gitCloneRepositoryAndCheckoutIn: >>> aDirectoryName) >>> >>> Is anybody able to clone a git repo from a Pharo image in Windows? >>> >>> from iPad >>> >> >> > >

Sept. 23, 2014

Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil

by ClÃ©ment Bera

The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another process (so topContext was not assigned even if in an ensure block). I've tried to fix it but I failed. Can you give a reproduceable case ? And open a bug tracker issue with it ? Thanks. 2014-09-23 16:45 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: > Sorry, the message is #stepToCallee (without the colon, my bad). > in 40243 I still get it. > > > > > 2014-09-23 16:30 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: > >> pharo 4, but not the latest image >> >> 2014-09-23 16:27 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> In the latest Pharo 4, #stepToCallee: is not implemented nor sent. >>> >>> Which version of Pharo are you using ? >>> >>> >>> 2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: >>> >>>> Hi! >>>> When debugging tests, if I just close the debugger without finishing >>>> the test run, I get this weird message. Has anybody had this problem >>>> before? >>>> >>> >>> >> >

Sept. 23, 2014

[pharo-project/pharo-core] 76afae: 40246

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 76afaea90a740f5ad12894728a78701d18045363 https://github.com/pharo-project/pharo-core/commit/76afaea90a740f5ad1289472… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-23 (Tue, 23 Sep 2014) Changed paths: M AST-Interpreter-Core.package/AIBlockContext.class/class/instance creation/fromVMContext_.st R AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/findNextHandlerContextStarting.st M AST-Interpreter-Core.package/ExceptionHandler.class/definition.st R AST-Interpreter-Core.package/ExceptionHandler.class/instance/accessing/enabled.st R AST-Interpreter-Core.package/ExceptionHandler.class/instance/accessing/enabled_.st M AST-Interpreter-Core.package/ExceptionHandler.class/instance/exception-handling/handle_.st R AST-Interpreter-Core.package/ExceptionHandler.class/instance/initialization/initialize.st M AST-Interpreter-Core.package/ExceptionHandler.class/instance/testing/handles_.st M Kernel.package/BlockClosure.class/instance/exceptions/on_do_.st M Kernel.package/Context.class/instance/private-exceptions/canHandleSignal_.st R Kernel.package/Context.class/instance/private-exceptions/findNextHandlerContextStarting.st R Kernel.package/Context.class/instance/special context access/exceptionHandlerIsActive.st R Kernel.package/Context.class/instance/special context access/exceptionHandlerIsActive_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script246.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40246.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40246 11996 Wrong exception handler problem (parrt 5/5) https://pharo.fogbugz.com/f/cases/11996 http://files.pharo.org/image/40/40246.zip

Sept. 23, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40246 Home: https://github.com/pharo-project/pharo-core

Sept. 23, 2014