- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Nautilus roadmap / icons

by Eliot Miranda

Hi Marcus, On Thu, Sep 25, 2014 at 11:29 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 25 Sep 2014, at 23:02, phil(a)highoctane.be wrote: > > > Well, the full story is that the decompiler is now gone with Opal. > > > There is a decompiler again in Pharo4 > > > So, there were 3 in the beginning. So, of course with 2, this becomes a > switch. > > > > Why no decompiler anymore, for the layman I am? > > > The *option* of showing decompiled code in the browser: Honestly, I do not > get > why this was useful, ever. > I can think of three reasons. 1. mutable literals. using the decompiler is a quick way to check if a literal has been corrupted/modified 2. if you're working on the decompiler this is convenient 3. when Dan's encode temp names in trailer and decompile scheme was being developed/used there would be no need to display sources > Marcus > -- best, Eliot

Sept. 26, 2014

Re: [Pharo-dev] Windows not interactive

by Max Leske

I can confirm that the bug has existed since at least 1.3. I saw it a couple of weeks back and had to do SystemWindow allSubInstances do: #close to get rid of them. Canât provide more detail though. Iâll keep my eyes open though. Max On 26.09.2014, at 19:35, stepharo <stepharo(a)free.fr> wrote: > yes we do not know how to reproduce this bug and it is annoying. > > > On 26/9/14 13:30, Natalia Tymchuk wrote: >> Hi. >> I got the situation when all my windows are not interactive and when I click somewhere on windows and tabs the world menu appears. However I can open new window and work with it. >> What should I do in this situation? >> Best regards, >> Natalia >> >> > >

Sept. 26, 2014

Re: [Pharo-dev] [Review: 11536] Add Stream >> printString:

by Max Leske

On 26.09.2014, at 18:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 26 Sep 2014, at 18:21, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> >> >> On Fri, Sep 26, 2014 at 6:20 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> On 20.09.2014, at 03:02, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> 2014-09-19 20:59 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> >>>> >>>> On Fri, Sep 19, 2014 at 1:19 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>> >>>>> This issue was more of a discussion between Camillo and Sven. They never >>>>> reached a conclusion, so please take a look. Iâve compiled the transcript >>>>> below. >>>>> >>>>> The issue isnât easy to solve and maybe we can just close it as ânot >>>>> importantâ. >>>> >>>> >>>> +1. But isn't the selector printString: broken? >>> >>> >>> The selector sounds broken to me too. >>> >>> I always bring Dolphin to the discussion, but Dolphin streams had both >>> #print:/#display: >>> >>> WriteStream>>#print: anObject >>> anObject printOn: aStream. >>> >>> WriteStream>>#display: anObject >>> anObject displayOn: aStream. >>> >>> But those are for printing/displaying the argument on the stream, >>> which is not exactly the same as sending #asString and then then >>> appending the result to receiver. So Eliot's #printAsString: seems to >>> be the most intention revealing selector for such task. >> >> Ok, so how about adding WriteStream>>printAsString:? Implementation: >> >> printAsString: anObject >> self nextPutAll: anObject asString >> >> If you add this it also needs to be added to whatever the transcript streams are. The two should have the same protocol for writing. Right now there are a number of missing methods on the transcript side. > > I still don't like it, we're just adding methods, making the API fatter, for what exactly ? > > What is the difference between > > stream printAsString: foo > > and > > stream << foo asString None really. Actually I donât quite see why #asString should ever be sent (except for during error handling maybe). I usually override #printOn: for displaying information about an object during development and use a specific implementation when I want to store an object on a stream. So I rarely need #asString in combination with streams. > > ? > > Do we really need this ? No, I guess not. It has worked fine so far. But since the discussion was opened I thought Iâd push a little :) So: anybody opposed to closing this issue? Cheers, Max > > Sven

Sept. 26, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 26, 2014

[pharo-project/pharo-core] 6e4318: 40262

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6e4318b1abaf7b7100ec387e2776ade23a163f10 https://github.com/pharo-project/pharo-core/commit/6e4318b1abaf7b7100ec387e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-26 (Fri, 26 Sep 2014) Changed paths: M KernelTests.package/ClassHierarchyTest.class/class/fixing/fixSlotScope.st M Nautilus.package/AbstractNautilusUI.class/instance/private/runTestsOfClass_notifying_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script262.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/scriptnil.st M ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40261.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40262.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40262 13606 testSlotScopeParallelism is failing https://pharo.fogbugz.com/f/cases/13606 14085 Image blocked when halt placed on setUp method and running a whole TestCase from Nautilus https://pharo.fogbugz.com/f/cases/14085 http://files.pharo.org/image/40/40262.zip

Sept. 26, 2014

Re: [Pharo-dev] Exceptions chapter of Deep Into Pharo

by Martin McClure

On 09/25/2014 04:08 AM, Damien Cassou wrote: > On Thu, Sep 25, 2014 at 10:27 AM, stepharo <stepharo(a)free.fr> wrote: >> martin what is your account name? >> because I could not find you in the user list > > > it is possible that his account is not yet visible because > unconfirmed. Martin has to wait for an answer from the help center. > Right. Finally got that straightened out, and have entered my request to join the project. Account name is martinmcclure. Regards, -Martin

Sept. 26, 2014

Re: [Pharo-dev] Windows not interactive

by stepharo

yes we do not know how to reproduce this bug and it is annoying. On 26/9/14 13:30, Natalia Tymchuk wrote: > Hi. > I got the situation when all my windows are not interactive and when I click somewhere on windows and tabs the world menu appears. However I can open new window and work with it. > What should I do in this situation? > Best regards, > Natalia > >

Sept. 26, 2014

Re: [Pharo-dev] [Review: 11536] Add Stream >> printString:

by Sven Van Caekenberghe

On 26 Sep 2014, at 18:21, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Sep 26, 2014 at 6:20 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 20.09.2014, at 03:02, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > 2014-09-19 20:59 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> > >> > >> On Fri, Sep 19, 2014 at 1:19 AM, Max Leske <maxleske(a)gmail.com> wrote: > >>> > >>> This issue was more of a discussion between Camillo and Sven. They never > >>> reached a conclusion, so please take a look. Iâve compiled the transcript > >>> below. > >>> > >>> The issue isnât easy to solve and maybe we can just close it as ânot > >>> importantâ. > >> > >> > >> +1. But isn't the selector printString: broken? > > > > > > The selector sounds broken to me too. > > > > I always bring Dolphin to the discussion, but Dolphin streams had both > > #print:/#display: > > > > WriteStream>>#print: anObject > > anObject printOn: aStream. > > > > WriteStream>>#display: anObject > > anObject displayOn: aStream. > > > > But those are for printing/displaying the argument on the stream, > > which is not exactly the same as sending #asString and then then > > appending the result to receiver. So Eliot's #printAsString: seems to > > be the most intention revealing selector for such task. > > Ok, so how about adding WriteStream>>printAsString:? Implementation: > > printAsString: anObject > self nextPutAll: anObject asString > > If you add this it also needs to be added to whatever the transcript streams are. The two should have the same protocol for writing. Right now there are a number of missing methods on the transcript side. I still don't like it, we're just adding methods, making the API fatter, for what exactly ? What is the difference between stream printAsString: foo and stream << foo asString ? Do we really need this ? Sven

Sept. 26, 2014

Re: [Pharo-dev] [Vm-dev] Re: catching FFI errors

by Eliot Miranda

On Fri, Sep 26, 2014 at 7:59 AM, Ben Coman <btc(a)openinworld.com> wrote: > > Eliot Miranda wrote: > >> Hi Ben, >> >> On Sep 25, 2014, at 5:50 PM, Ben Coman <btc(a)openInWorld.com> wrote: >> >> I had a brief moment wondering about the general problem we have when >>> calling out through FFI that we expose ourselves to bugs in the external >>> library that crash the Image. I wonder... >>> >>> 1. Debuggers like gdb can run a program that crashes, without themselves >>> itself crashing. Could our FFI calls be wrapped in similar mechanism? >>> >>> 2. Languages have exception handling, so that errors like divide by zero >>> can be caught. Could our FFI calls be wrapped in similar mechanism? cheers >>> -ben >>> >> >> one thing that is pretty straight-forward to do is to catch and report >> errors during FFI calls as primitive failures with error codes. I added >> this to the VisualWorks VM a while ago It works like this: >> >> 1. The VM installs a first-level exception handler (windows) or signal >> handlers for SIGSEGV et al (unix). (This is something the VM already does). >> >> 2. When an FFI call out is made the VM can find the activation they made >> an FDI call out. It must be able to do this if it is to handle a callback. >> >> 3. An FFI call out is modified to set a flag, eg inFFICall, that is >> tested by the first-level exception handler. The flag is cleared when the >> FFI call completes or cleared when taking a callback and restored when the >> callback returns. >> >> 4. When the first level exception/signal handler is invoked it tests the >> inFFICall flag. If unset it does what it always did (exit, do nothing, >> etc). If the flag is set it collects the error information, located the >> FFI activation for the FFI call, does a long jump that returns from the FFI >> call as a primitive failure, supplying the error information. >> >> Now this is useful because the VM doesn't crash (provided the error was >> localized in its effects and didnt eg corrupt the heap), and hence easy for >> the developer to find out which FFI call provoked the error, but not as >> useful as catching the error in gdb. The exception info is typically an >> exception code and an address, which may be difficult for the programmer to >> decode. Hence the mechanism needs to be made optional, typically in by >> default, and then disabled to investigate under gdb. >> >> Does this sound useful? >> >> Eliot (phone) >> > > Its good to know how that works, and that it is standard already. Now I > wonder, (though it might not be portable) would it be feasible to use > something like mprotect to make the Image memory read-only for the duration > of the FFI call? Maybe even use a separate segment just for FFI calls (is > it even possible for processes to have additional segments than the usual > heap/stack/? > I suspect not on conventional hardware. On the one hand, it would cost too much. You might time how long it takes to mprotect the heap. If you do let me know. But since mprotect is a system call it will have overhead at least that of a typical FFI call. On the other hand, some FFI calls are reads and are made to read data into the heap. The complications of dealing with this (only protecting part of the heap, or allocating a temporary buffer and double-copying the data) are again costs and complications to be avoided. But I was talking to David Chisnall at ESUG and he and colleagues are working on special hardware (implemented in FPGA) on which they do their OO and OS work. This is a capability machine and it allows FFI calls to be invoked cheaply with a capability that excludes writing to the heap. > Thanks for the detailed reply Eliot, but note (and I should have said > already), these are idle thoughts. I'll file answers for later reference, > but its not something I'm working on right now. > You're welcome. -- best, Eliot

Sept. 26, 2014

Re: [Pharo-dev] [Review: 11536] Add Stream >> printString:

by Eliot Miranda

On Fri, Sep 26, 2014 at 6:20 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 20.09.2014, at 03:02, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > 2014-09-19 20:59 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> > >> > >> On Fri, Sep 19, 2014 at 1:19 AM, Max Leske <maxleske(a)gmail.com> wrote: > >>> > >>> This issue was more of a discussion between Camillo and Sven. They > never > >>> reached a conclusion, so please take a look. Iâve compiled the > transcript > >>> below. > >>> > >>> The issue isnât easy to solve and maybe we can just close it as ânot > >>> importantâ. > >> > >> > >> +1. But isn't the selector printString: broken? > > > > > > The selector sounds broken to me too. > > > > I always bring Dolphin to the discussion, but Dolphin streams had both > > #print:/#display: > > > > WriteStream>>#print: anObject > > anObject printOn: aStream. > > > > WriteStream>>#display: anObject > > anObject displayOn: aStream. > > > > But those are for printing/displaying the argument on the stream, > > which is not exactly the same as sending #asString and then then > > appending the result to receiver. So Eliot's #printAsString: seems to > > be the most intention revealing selector for such task. > > Ok, so how about adding WriteStream>>printAsString:? Implementation: > > printAsString: anObject > self nextPutAll: anObject asString > If you add this it also needs to be added to whatever the transcript streams are. The two should have the same protocol for writing. Right now there are a number of missing methods on the transcript side. > > > Cheers, > Max > > > > > Regards! > > > > > -- best, Eliot

Sept. 26, 2014