- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Chris Muller

On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-09-16 14:37 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: > >> Well, a while ago in the business list Iâve raised the idea that making >> Pharo able to do native OS windows would help it to gain market space (as in >> the opposite of staying at the margins of it). >> >> So, Iâd be very positively curious about being able to use Pharo to do >> multiplatform native apps > > The trend is shifting to mobile devices, iOS and Android are eating > the whole market. So if it is about the potential market size, native > mobile (tablets/phones/TVs) should come as the first option, before > desktop. +1. Desktop apps are "dead" aren't they? I'm doubtful that native windows would help Smalltalk's popularity, as evidenced, I guess, by the fact VA and VW have supported them for a long time; did they take over the world yet? > For development, native windows could prove very useful. How so? For me, one of the worst aspects of trying to develop in VisualAge or VisualWorks *is* the multiple host windows. It makes it virtually impossible to work in more than one image, and reinforces the "grand cathedral" thinking about Smalltalk; e.g. you're not supposed to want or need anything outside your one, true, image. Dinosaur! I constantly work in multiple images, not only for separate projects but for the ability to quickly and easily fork images for multicore processing on the same project. Other times simply to try something temporary and possibly dangerous. The memory isolation is critical for productivity, the UI isolation for usability, and the multi-core capability for performance. I think we should focus on how to move to more and smaller intercommunicating images rather than one big image. I understand its appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware of any other use-cases where multiple host windows would be preferable to one host window per image.

Sept. 16, 2014

Re: [Pharo-dev] AppeX

by Thierry Goubier

Hi Doru, I'm looking through it. Interestingly simple :) You do have the styler inside another styler stuff working (smalltalk code styler inside a Pillar code bloc) which is very neat. Thierry Le 15/09/2014 06:44, Tudor Girba a Ã©crit : > Hi, > > As you could see in the Pillar highlighting support, Rubric can now > handle any syntax highlighting in a rather straightforward way. You > can also easily embed this in a Glamour browser. > > You can see the example in the GT-InspectorExtensions-Pillar. You can > load the code in a Moose image like this: > Gofer new > smalltalkhubUser: 'Pier' project: 'Pillar'; > configuration; > loadStable. > Gofer new > smalltalkhubUser: 'JanKurs' project: 'PetitParser'; > configurationOf: #PetitParserIslands; > load. > #ConfigurationOfPetitParserIslands asClass loadDevelopment. > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Pillar'; > load. > > Cheers, > Doru > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Sept. 16, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

by Tudor Girba

Great! I will go over it more thoroughly in the following weeks and get back to you with feedback. Cheers, Doru On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Dear all, > > We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro > Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for > Pharo) and Hapao2. > Hapao2 is about assessing the test coverage of your code and is a major > revamp of Hapao1, which was presented a couple of years ago by Vanessa. > Hapao2 does not only list covered and uncovered methods, as most test > coverage tool on Earth will do. Hapao gives a great visualization to easily > navigate in your code, assess its complexity, and give you a great visual > output telling its coverage. > > You need Roassal in your image: > > Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'Roassal2'; > package: 'ConfigurationOfRoassal2'; > load. > (Smalltalk at: #ConfigurationOfRoassal2) load > > > and you need S2py: > MCHttpRepository > location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' > user: '' > password: '' > > > New entries will appear in the world menu: > > > You can run the test coverage on : > - the class classes you have modified, > - on a particular > - on a particular class category > - on the last class categories you have modified > - on the last packages you have modified > > Here is a portion of a large coverage: > > > A technical description of Hapao may be found on > http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf > > We are daily using Hapao to help us understand our tests. > > Cheers, > Ricardo, Alejandro & Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 16, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Esteban A. Maringolo

2014-09-16 14:37 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: > Well, a while ago in the business list Iâve raised the idea that making > Pharo able to do native OS windows would help it to gain market space (as in > the opposite of staying at the margins of it). > > So, Iâd be very positively curious about being able to use Pharo to do > multiplatform native apps The trend is shifting to mobile devices, iOS and Android are eating the whole market. So if it is about the potential market size, native mobile (tablets/phones/TVs) should come as the first option, before desktop. For development, native windows could prove very useful. Regards!

Sept. 16, 2014

Re: [Pharo-dev] Looks like implementors in smart suggestion does not work anymore

by stepharo

removing SugsNautilusContext>>tools fixes the problem but may be it open new ones On 16/9/14 20:49, stepharo wrote: > Hi > > can somebody confirm? > in Nautilus in text pane implementors in smart suggestion does not > work anymore > > Stef > >

Sept. 16, 2014

Re: [Pharo-dev] DateModel not working in 3.0

by stepharo

Super we will have a look, just buzy buzzy buzzzy > Sean P. DeNigris wrote >> Will someone please review... > Ready to integrate in 3.0 - merges and passes manual test > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/DateModel-not-working-in-3-0-tp4778355p4778420.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Sept. 16, 2014

Looks like implementors in smart suggestion does not work anymore

by stepharo

Hi can somebody confirm? in Nautilus in text pane implementors in smart suggestion does not work anymore Stef

Sept. 16, 2014

Re: [Pharo-dev] I'm confused about Process>>isTerminated

by Eliot Miranda

Hi Max, On Tue, Sep 16, 2014 at 11:05 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi > > As always when I want to check if a process has died I get very confused > by #isTerminated and Iâm wondering if I just donât get how itâs supposed to > work or if there are others that share my confusion. > > Old implementation: > > isTerminated > > self isActiveProcess ifTrue: [^ false]. > ^suspendedContext isNil > or: ["If the suspendedContext is the bottomContext it is the > block in Process>>newProcess. > If so, and the pc is greater than the startpc, the bock > has alrteady sent and returned > from value and there is nothing more to do." > suspendedContext isBottomContext > and: [ suspendedContext pc > suspendedContext startpc ] ] > > > Pharo 4 implementation: > > isTerminated > self isActiveProcess ifTrue: [^ false]. > ^suspendedContext isNil > or: ["If the suspendedContext is the bottomContext it is the > block in Process>>newProcess. > If so, and the pc is greater than the startpc, the bock > has alrteady sent and returned > from value and there is nothing more to do.â > suspendedContext isBottomContext > and: [ suspendedContext isDead not > â<âââââââââââââââââââââââââ new" > and: [ suspendedContext pc > suspendedContext startpc ] ] ] > > > The old implementation would break if the suspended context was dead (i.e. > the pc was nil) because the send of #> would produce an MNU. > The new implementation doesnât fix that, even though it looks like it at > first glance: if the pc is nil, the #> send will still happen -> MNU. > Off the top of my head it would seem that it should be isDead or: [] not isDead not and: isTerminated self isActiveProcess ifTrue: [^ false]. ^suspendedContext isNil or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. If so, and the pc is greater than the startpc, the bock has alrteady sent and returned from value and there is nothing more to do.â suspendedContext isBottomContext and: [ suspendedContext isDead or: [ suspendedContext pc > suspendedContext startpc ] ] ] > isDead > ^ pc isNil > and maybe (suspendedContext pc ifNil: [true] ifNotNil: [:pc| pc > suspendedContext startpc]) is more obvious. Anyway, neither implementation will reliably tell me if the process has > been terminated: > - an inactive process will be suspended when #terminate is sent and report > that it has not been terminated (#isSuspended -> true, #isTerminated -> > false) > except that it *hasn't* been terminated, it is merely in the process of termination. It isn't terminated until all unwind blocks have run, right? > - a properly terminated process will raise an MNU (although apparently not > alwaysâ¦?) > but that's a bug the change I suggested will fix. > - all the states in between: no clue > > I would like to know two things: > 1. how can I check if a process has already *received* a #terminate? (I > would then assume that the process will die eventually) > I don't think you can without putting a critical section around terminate and adding some process-specific variable that is set when you send terminate. termination is not instantaneous (unwind blocks have to be run), so it is potentially interruptible. > 2. how can I check if a process is *actually* dead? (in case a âhalf deadâ > process will still unwind or whatever) > see above. > > What would be necessary to make those tests (or better ones) possible > (rewrite the whole process implementation?)? > > > Cheers, > Max > -- best, Eliot

Sept. 16, 2014

I'm confused about Process>>isTerminated

by Max Leske

Hi As always when I want to check if a process has died I get very confused by #isTerminated and Iâm wondering if I just donât get how itâs supposed to work or if there are others that share my confusion. Old implementation: isTerminated self isActiveProcess ifTrue: [^ false]. ^suspendedContext isNil or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. If so, and the pc is greater than the startpc, the bock has alrteady sent and returned from value and there is nothing more to do." suspendedContext isBottomContext and: [ suspendedContext pc > suspendedContext startpc ] ] Pharo 4 implementation: isTerminated self isActiveProcess ifTrue: [^ false]. ^suspendedContext isNil or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. If so, and the pc is greater than the startpc, the bock has alrteady sent and returned from value and there is nothing more to do.â suspendedContext isBottomContext and: [ suspendedContext isDead not â<âââââââââââââââââââââââââ new" and: [ suspendedContext pc > suspendedContext startpc ] ] ] The old implementation would break if the suspended context was dead (i.e. the pc was nil) because the send of #> would produce an MNU. The new implementation doesnât fix that, even though it looks like it at first glance: if the pc is nil, the #> send will still happen -> MNU. isDead ^ pc isNil Anyway, neither implementation will reliably tell me if the process has been terminated: - an inactive process will be suspended when #terminate is sent and report that it has not been terminated (#isSuspended -> true, #isTerminated -> false) - a properly terminated process will raise an MNU (although apparently not alwaysâ¦?) - all the states in between: no clue I would like to know two things: 1. how can I check if a process has already *received* a #terminate? (I would then assume that the process will die eventually) 2. how can I check if a process is *actually* dead? (in case a âhalf deadâ process will still unwind or whatever) What would be necessary to make those tests (or better ones) possible (rewrite the whole process implementation?)? Cheers, Max

Sept. 16, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Sebastian Sastre

On Sep 15, 2014, at 3:54 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > The native windows contain morphs, but anything, including MVC, can be present. This provides native Win32 Windows (doing other platforms is merely work) /and/ the ability to snapshot and bring back up windows on a different platform (e.g. open in win32, snapshot and bring up in Squeak/Pharo Morphic windows, or vice verse), and the ability to do this dynamically. Is anyone motivated to port the Newspeak code back to Squeak/Pharo? Well, a while ago in the business list Iâve raised the idea that making Pharo able to do native OS windows would help it to gain market space (as in the opposite of staying at the margins of it). So, Iâd be very positively curious about being able to use Pharo to do multiplatform native apps sebastian o/

Sept. 16, 2014