- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GT inspector: how to get side by side panes

by Tudor Girba

Hi, This is not really possible in the current implementation. Cheers, Doru > On May 21, 2016, at 9:03 AM, stepharo <stepharo(a)free.fr> wrote: > > I would like to see different views of a compiled method (source, bytecode) side by side > > > Is there a way to see a new pane (describing a different aspect) on the right without been force to click on > > an element of the objects? > > I tried option alt control + click > > > Stef > > > -- www.tudorgirba.com www.feenk.com "To utilize feedback, you first have to acquire it."

May 21, 2016

GT inspector: how to get side by side panes

by stepharo

I would like to see different views of a compiled method (source, bytecode) side by side Is there a way to see a new pane (describing a different aspect) on the right without been force to click on an element of the objects? I tried option alt control + click Stef

May 21, 2016

Re: [Pharo-dev] Turning off Spotter using internet!

by stepharo

Thanks sven. I'm working on image without personal setting and often in places with no internet (or full of wifis but that I cannot connect to :). Stef >> On 19 May 2016, at 13:41, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guys >> >> This is hyper annoying that Spotter look for the net by default. >> >> We should turn it off. > This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image. > > The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way. > > This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me. > > That is the issue that we should fix. > > Assuming someone has no internet, and force them to manage the connection state themselves manually, seems very backward to me - in this century. > > So I vote against turning it off. > >> We should also improve the comment of the catalog setting because it is unclear >> >> that this is this setting that should be turned off. > Yes that would be good. > >> Stef >> >> > >

May 21, 2016

Re: [Pharo-dev] Pharo IDE in Amber?

by Pierce Ng

On Fri, May 20, 2016 at 02:58:21PM +0200, Siemen Baader wrote: > If this can be overcome, I think the options would be to either: > a) implement a Morphic raster rendering backend based on HTML5 Canvas, or: > 2) create DOM & CSS based Morphic widgets, like the Lively Kernel does. iii) Take a look at the Shampoo protocol: https://github.com/dmatveev/shampoo. With a Shampoo client in Pharo and a Shampoo server in Amber, you can use Pharo as your Amber IDE. Of course initially this is just using the Pharo IDE as an editor for programming Amber and doesn't offer much integration, but once the connectivity is there, I'm sure other possibilities open up. Btw, I cooked up what I called MorphIDE in 2011 when Amber was Jtalk. But eventually I didn't use Jtalk for anything so MorphIDE didn't grow beyond the proof of concept. See http://www.samadhiweb.com/blog/2011.09.03.morphide.html. Also, the Jtalk/Amber examples on my blog may not work because the JS files were lost when I moved the blog across machines. Pierce

May 21, 2016

Re: [Pharo-dev] Minutes of the Meeting to Discuss Moving Cog to Github

by Torsten Bergmann

May 21, 2016

Re: [Pharo-dev] [Vm-dev] Minutes of the Meeting to Discuss Moving Cog to Github

by Eliot Miranda

Hi Juan, On Fri, May 20, 2016 at 12:57 PM, Juan Vuletich <JuanVuletich(a)zoho.com> wrote: > Hi Folks, > > This is just great! > > I assume builds will include: > - V3, Cog, 32bitBinaries > - Spur32, Cog, 32bitBinaries > - Spur64, Cog, 64bitBinaries > Yes. > > Would it also be possible to include: > - V3, Stack, 32bitBinaries > - Spur32, Stack, 32bitBinaries > - Spur64, Stack, 64bitBinaries > ? > I think so. Tim F tells me that Github support for open source projects is free, including disk space, so there's nothing to stop us including a comprehensive suite of VMs. > I think that having the non-Cog builds always green could benefit those > platforms where code generation is not possible, and might ease porting to > new platforms. Especially for Spur64. > Indeed, I hope that with the new repository it will be much easier for the people who got the VM working on iPad to integrate their changes. It should also be possible to have Linux ARM v6 (Pi) and Linux ARM v7 (Android) VMs. > > Thanks you all! > Juan Vuletich > > > On 5/20/2016 2:28 PM, Eliot Miranda wrote: > > > > Hi All, > > here are the minutes of, and action items arising from, the meeting on > Wednesday 18th of May to discuss moving the Cog svn repository to Github. > Please read if you're interested and discuss on vm-dev. The major decision > for the community to participate in is when to make the change, which we > hope will happen in the next few weeks. Thanks to all who attended the > meeting and to all who have helped in making this a reality. This is > exciting! > > VM Move to Github Meeting Notes > > The name of the organisation and repository was agreed to be, and has been > created as > > Organisation name: OpenSmalltalk > > Repository name: vm > > URL: github.com/OpenSmalltalk/vm > > Administration duties: > > - > > Tim Felgentreff, David Lewis, Esteban Lorenzano, Eliot Miranda > > > We decided to have everyone who currently has access to SVN also get write > access to the new repository. > > There will be a master branch that is stable and from which releases are > made using tags. Only administrators integrate into that branch. Ongoing > development will be on a âdevâ branch. This should also be kept stable for > collaboration purposes, but breakage can happen occasionally. Contributors > working on larger changes will do so on separate branches to avoid > conflicts/breaking other peopleâs code. > > Every commit will be tested by Travis (and Appveyor for Windows). Builds > and tests will be run for Windows, Linux, and OS X, both on 32-bit, 64-bit, > and ARM (as applicable). The master will only ever be merged with green > commits. The dev branch should be green, and if something breaks, but the > committer has no access or no time to fix it, we agreed that any > administrator may roll back the breaking change using git revert. This way, > the breaking change is preserved in the history, but the current HEAD is > green. We will also disable âforce-pushingâ to the repository to ensure > that no commit history can be tampered with. > > In case of any disagreements about reverting other peopleâs code, we > declared Eliot (*) to be the arbiter. > > Release tags on the master will trigger Travis to build release artifacts, > including debian packages. > > To have incremental monotonic, human-readable version identifiers, we > decided to use timestamps in the form YYYYMMDDHHmm in UTC. In order to > ensure these timestamps are included in the sources, we will have a commit > script in the repository that any contributor must use to update the dev > and master branches (**). The checkout command for any version then becomes > âgit checkout branch@{timestamp}â. Both the built VMs via a -version > flag, and sources via a header file, will be marked with these timestamps. > > It was decided to leave the build system as-is using GNU Makefiles where > available with a commitment to move to GNU Makefiles on Linux. We will use > CMake to produce per-platform config files that identify platform > facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3)). > > We discussed ethics, which derive from the âif you break it, you fix itâ > philosophy and distilled it into the âadministrators may revertâ policy > above. We donât want to prevent breakages, nor make people afraid of > breaking things. We merely want to prevent other people being affected by > breakages, especially those that may be operating under production or time > constraints. > > We will integrate the Github commit notifications with a Codespeed > instance that will test commits for performance regressions. > > Action Items > > > - > > Write the commit script > - > > Set a date for the move (sooner rather than later) > - > > Move the repository > - > > Enable automatic builds for all the platforms > - > > Write GNU makefiles for unix/linux > - Make WebHooks for Commit Notifications available to anyone who wants > them. > - Write CMake code to generate per-platform headers (***) > > > > _,,,^..^,,,_ > best, Eliot > > (*) under protest > (**) use whatever versioning you want on your own versions, but the > versions in OpenSmalltalk/vm will use this convention exclusively > (***) which will /not/ be called "config.h", but e.g. "ostvmConfig.h", so > as to avoid conflicts with other packages using autoconf and CMake > > > -- _,,,^..^,,,_ best, Eliot

May 20, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Ben Coman

On Sat, May 21, 2016 at 12:05 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Ben, for the record, I am using DelayMillisecondScheduler for a day and a > half and so far no problem. Cool. Thats why I left it there. I hope to soon have something for you to try with the newer design. Thanks for the update. cheers -ben > On Thu, May 19, 2016 at 9:19 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> >> On Wed, May 18, 2016 at 9:49 PM, Martin McClure <martin(a)hand2mouse.com> >> wrote: >>> >>> On 05/18/2016 03:17 PM, Martin McClure wrote: >>>> >>>> On 05/18/2016 08:49 AM, Mariano Martinez Peck wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot >>>>> explain how this could happened but it does, and it happened to me a couple >>>>> of times (but not fully reproducible). >>>>> >>>> >>>> Hmm. The schedulerResumptionTime is, somehow, being (approximately) >>>> doubled. It's not clear how that can happen, but I'll look a little more. >>>> >>> >>> Mario, is there any chance that you might be saving the image during one >>> of these Delays? >>> >>> >>> This one smells like a race condition, and I think I see something that >>> *might* explain it. But I don't have any more time to spend on this one, so >>> I'll leave the rest to someone else. I hope this is helpful: >>> >>> The only way I immediately see for the schedulerResumptionTime to become >>> approximately doubled is if the Delay's resumption time is adjusted by >>> #restoreResumptionTimes without previously having been adjusted by >>> #saveResumptionTimes. >>> >>> The only time either of those are sent, that I can see, is on saving the >>> image. Both are normally sent, (save before the snapshot, restore >>> afterwards), but there may be a hole there. >>> >> >> Martin, first off, thanks for the research!!! >> >> Now....your email made me remember something: I did get VM crash when >> saving the image a couple of times. The VM crashed when saving the image. If >> I re-opened the image, it looks like if the image was indeed saved (so the >> snapshot primitive itself did work), but I suspect not all shutdown code >> could have been run correctly. >> >> The VM crash looks like the FreeTypeFace >> pvtDestroyHandle which, as >> far as I know, it's a "known crash" (I attach crash dump). From what I can >> see, if I follow all the stack, the crash starts from the WeakArray >> >> startUp: . >> That means that...depending on the order of the startup list...the >> Scheduler may not have been run after the crash. >> >> Now.... WeakArray initialization does: >> >> SessionManager default >> registerSystemClassNamed: self name. >> While... >> >> Delay class >> startUp "Restart active delay, if any, when resuming a >> snapshot." Scheduler startUp. >> >> And the Delay registration is >> >> SessionManager default >> registerSystemClassNamed: self name >> atPriority: 20. >> >> So...that seems correct... >> >> I can verify this by: >> >> SessionManager default systemCategory prioritizedList >> >> Anyway...not sure if this adds something, but just wanted to note this. >> >> >>> >>> #saveResumptionTimes is only sent (by this scheduler class) when the >>> accessProtect semaphore is held, but #handleTimerEvent: is executed in the >>> timing Process *without* the protection of accessProtect, in the case of the >>> VM signaling the timingSemaphore. If the VM signals the timingSemaphore, >>> #handleTimerEvent: could run in the middle of #saveResumptionTimes. If some >>> Delay expires because of that timer event, our Delay could move from being >>> the first suspended delay to being the active delay. If that happens after >>> we've adjusted the active delay, but before we've processed the suspended >>> delays, that Delay will not get adjusted, and will show the symptoms that >>> Mariano is seeing. >>> >>> Also, I'm not sure how the Heap that holds the suspendedDelays will react >>> to being modified in the middle of an enumeration. That might open a larger >>> window for the problem. >>> >>> Regards, >>> >>> -Martin >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

May 20, 2016

Re: [Pharo-dev] [Vm-dev] Minutes of the Meeting to Discuss Moving Cog to Github

by Tudor Girba

Hi, Thank you very much to everyone involved for making this happen! Cheers, Doru > On May 20, 2016, at 7:28 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > here are the minutes of, and action items arising from, the meeting on Wednesday 18th of May to discuss moving the Cog svn repository to Github. Please read if you're interested and discuss on vm-dev. The major decision for the community to participate in is when to make the change, which we hope will happen in the next few weeks. Thanks to all who attended the meeting and to all who have helped in making this a reality. This is exciting! > > VM Move to Github Meeting Notes > The name of the organisation and repository was agreed to be, and has been created as > Organisation name: OpenSmalltalk > Repository name: vm > URL: github.com/OpenSmalltalk/vm > > Administration duties: > â¢ Tim Felgentreff, David Lewis, Esteban Lorenzano, Eliot Miranda > > We decided to have everyone who currently has access to SVN also get write access to the new repository. > > There will be a master branch that is stable and from which releases are made using tags. Only administrators integrate into that branch. Ongoing development will be on a âdevâ branch. This should also be kept stable for collaboration purposes, but breakage can happen occasionally. Contributors working on larger changes will do so on separate branches to avoid conflicts/breaking other peopleâs code. > > Every commit will be tested by Travis (and Appveyor for Windows). Builds and tests will be run for Windows, Linux, and OS X, both on 32-bit, 64-bit, and ARM (as applicable). The master will only ever be merged with green commits. The dev branch should be green, and if something breaks, but the committer has no access or no time to fix it, we agreed that any administrator may roll back the breaking change using git revert. This way, the breaking change is preserved in the history, but the current HEAD is green. We will also disable âforce-pushingâ to the repository to ensure that no commit history can be tampered with. > > In case of any disagreements about reverting other peopleâs code, we declared Eliot (*) to be the arbiter. > > Release tags on the master will trigger Travis to build release artifacts, including debian packages. > > To have incremental monotonic, human-readable version identifiers, we decided to use timestamps in the form YYYYMMDDHHmm in UTC. In order to ensure these timestamps are included in the sources, we will have a commit script in the repository that any contributor must use to update the dev and master branches (**). The checkout command for any version then becomes âgit checkout branch@{timestamp}â. Both the built VMs via a -version flag, and sources via a header file, will be marked with these timestamps. > > It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3)). > We discussed ethics, which derive from the âif you break it, you fix itâ philosophy and distilled it into the âadministrators may revertâ policy above. We donât want to prevent breakages, nor make people afraid of breaking things. We merely want to prevent other people being affected by breakages, especially those that may be operating under production or time constraints. > > We will integrate the Github commit notifications with a Codespeed instance that will test commits for performance regressions. > > Action Items > > â¢ Write the commit script > â¢ Set a date for the move (sooner rather than later) > â¢ Move the repository > â¢ Enable automatic builds for all the platforms > â¢ Write GNU makefiles for unix/linux > â¢ Make WebHooks for Commit Notifications available to anyone who wants them. > â¢ Write CMake code to generate per-platform headers (***) > > > _,,,^..^,,,_ > best, Eliot > > (*) under protest > (**) use whatever versioning you want on your own versions, but the versions in OpenSmalltalk/vm will use this convention exclusively > (***) which will /not/ be called "config.h", but e.g. "ostvmConfig.h", so as to avoid conflicts with other packages using autoconf and CMake -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

May 20, 2016

Minutes of the Meeting to Discuss Moving Cog to Github

by Eliot Miranda

Hi All, here are the minutes of, and action items arising from, the meeting on Wednesday 18th of May to discuss moving the Cog svn repository to Github. Please read if you're interested and discuss on vm-dev. The major decision for the community to participate in is when to make the change, which we hope will happen in the next few weeks. Thanks to all who attended the meeting and to all who have helped in making this a reality. This is exciting! VM Move to Github Meeting Notes The name of the organisation and repository was agreed to be, and has been created as Organisation name: OpenSmalltalk Repository name: vm URL: github.com/OpenSmalltalk/vm Administration duties: - Tim Felgentreff, David Lewis, Esteban Lorenzano, Eliot Miranda We decided to have everyone who currently has access to SVN also get write access to the new repository. There will be a master branch that is stable and from which releases are made using tags. Only administrators integrate into that branch. Ongoing development will be on a âdevâ branch. This should also be kept stable for collaboration purposes, but breakage can happen occasionally. Contributors working on larger changes will do so on separate branches to avoid conflicts/breaking other peopleâs code. Every commit will be tested by Travis (and Appveyor for Windows). Builds and tests will be run for Windows, Linux, and OS X, both on 32-bit, 64-bit, and ARM (as applicable). The master will only ever be merged with green commits. The dev branch should be green, and if something breaks, but the committer has no access or no time to fix it, we agreed that any administrator may roll back the breaking change using git revert. This way, the breaking change is preserved in the history, but the current HEAD is green. We will also disable âforce-pushingâ to the repository to ensure that no commit history can be tampered with. In case of any disagreements about reverting other peopleâs code, we declared Eliot (*) to be the arbiter. Release tags on the master will trigger Travis to build release artifacts, including debian packages. To have incremental monotonic, human-readable version identifiers, we decided to use timestamps in the form YYYYMMDDHHmm in UTC. In order to ensure these timestamps are included in the sources, we will have a commit script in the repository that any contributor must use to update the dev and master branches (**). The checkout command for any version then becomes âgit checkout branch@{timestamp}â. Both the built VMs via a -version flag, and sources via a header file, will be marked with these timestamps. It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3)). We discussed ethics, which derive from the âif you break it, you fix itâ philosophy and distilled it into the âadministrators may revertâ policy above. We donât want to prevent breakages, nor make people afraid of breaking things. We merely want to prevent other people being affected by breakages, especially those that may be operating under production or time constraints. We will integrate the Github commit notifications with a Codespeed instance that will test commits for performance regressions. Action Items - Write the commit script - Set a date for the move (sooner rather than later) - Move the repository - Enable automatic builds for all the platforms - Write GNU makefiles for unix/linux - Make WebHooks for Commit Notifications available to anyone who wants them. - Write CMake code to generate per-platform headers (***) _,,,^..^,,,_ best, Eliot (*) under protest (**) use whatever versioning you want on your own versions, but the versions in OpenSmalltalk/vm will use this convention exclusively (***) which will /not/ be called "config.h", but e.g. "ostvmConfig.h", so as to avoid conflicts with other packages using autoconf and CMake

May 20, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Mariano Martinez Peck

Ben, for the record, I am using DelayMillisecondScheduler for a day and a half and so far no problem. On Thu, May 19, 2016 at 9:19 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Wed, May 18, 2016 at 9:49 PM, Martin McClure <martin(a)hand2mouse.com> > wrote: > >> On 05/18/2016 03:17 PM, Martin McClure wrote: >> >>> On 05/18/2016 08:49 AM, Mariano Martinez Peck wrote: >>> >>>> Hi guys, >>>> >>>> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot >>>> explain how this could happened but it does, and it happened to me a couple >>>> of times (but not fully reproducible). >>>> >>>> >>> Hmm. The schedulerResumptionTime is, somehow, being (approximately) >>> doubled. It's not clear how that can happen, but I'll look a little more. >>> >>> >> Mario, is there any chance that you might be saving the image during one >> of these Delays? >> >> >> This one smells like a race condition, and I think I see something that >> *might* explain it. But I don't have any more time to spend on this one, so >> I'll leave the rest to someone else. I hope this is helpful: >> >> The only way I immediately see for the schedulerResumptionTime to become >> approximately doubled is if the Delay's resumption time is adjusted by >> #restoreResumptionTimes without previously having been adjusted by >> #saveResumptionTimes. >> >> The only time either of those are sent, that I can see, is on saving the >> image. Both are normally sent, (save before the snapshot, restore >> afterwards), but there may be a hole there. >> >> > Martin, first off, thanks for the research!!! > > Now....your email made me remember something:* I did get VM crash when > saving the image a couple of times. The VM crashed when saving the image. *If > I re-opened the image, it looks like if the image was indeed saved (so the > snapshot primitive itself did work), but I suspect not all shutdown code > could have been run correctly. > > The VM crash looks like the FreeTypeFace >> pvtDestroyHandle which, as > far as I know, it's a "known crash" (I attach crash dump). From what I can > see, if I follow all the stack, the crash starts from the WeakArray > >> startUp: . > That means that...depending on the order of the startup list...the > Scheduler may not have been run after the crash. > > Now.... WeakArray initialization does: > > SessionManager default > registerSystemClassNamed: self name. > While... > > Delay class >> startUp "Restart active delay, if any, when resuming a > snapshot." Scheduler startUp. > > And the Delay registration is > > SessionManager default > registerSystemClassNamed: self name > atPriority: 20. > > So...that seems correct... > > I can verify this by: > > SessionManager default systemCategory prioritizedList > > Anyway...not sure if this adds something, but just wanted to note this. > > > >> #saveResumptionTimes is only sent (by this scheduler class) when the >> accessProtect semaphore is held, but #handleTimerEvent: is executed in the >> timing Process *without* the protection of accessProtect, in the case of >> the VM signaling the timingSemaphore. If the VM signals the >> timingSemaphore, #handleTimerEvent: could run in the middle of >> #saveResumptionTimes. If some Delay expires because of that timer event, >> our Delay could move from being the first suspended delay to being the >> active delay. If that happens after we've adjusted the active delay, but >> before we've processed the suspended delays, that Delay will not get >> adjusted, and will show the symptoms that Mariano is seeing. >> >> Also, I'm not sure how the Heap that holds the suspendedDelays will react >> to being modified in the middle of an enumeration. That might open a larger >> window for the problem. >> >> Regards, >> >> -Martin >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

May 20, 2016