- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Lowering the pain of newbies

by Esteban A. Maringolo

What are the odds? The ability to break a system in a few steps seems to be an inherited trait. My daughter (2 years old) was randomly punching my keyboard and caused a segfault that I couldn't reproduce afterwards. Regards! Esteban A. Maringolo 2017-08-17 16:52 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi guys > > my son coded in Pharo 60 > > testGuessUrlPart > > |dg8| > dg8 := GameItem new; > name: 'Dragon Quest VIII : Journey Of The Cursed King'; > console: 'PS2'. > self assert: dg8 guessUrlPart equals: > 'dragonquestviiijourneyofthecursedking' > > and guess what he broke the system. > > We should not accept such kind of behavior. > name: should not change the name of the class. > > I do not know the solution but I fear when I will teach 160 students this fall. > We should make sure that Pharo is not a system only for experts! > > any idea is welcome > > https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-aut… > > Stef >

Aug. 17, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Cyril Ferlicot

On jeu. 17 aoÃ»t 2017 at 21:53, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guys > > my son coded in Pharo 60 > > testGuessUrlPart > > |dg8| > dg8 := GameItem new; > name: 'Dragon Quest VIII : Journey Of The Cursed King'; > console: 'PS2'. > self assert: dg8 guessUrlPart equals: > 'dragonquestviiijourneyofthecursedking' > > and guess what he broke the system. > > We should not accept such kind of behavior. > name: should not change the name of the class. > > I do not know the solution but I fear when I will teach 160 students this > fall. > We should make sure that Pharo is not a system only for experts! > > any idea is welcome > > > https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-aut… > > Stef > Fast answer: Some month (year?) ago I proposed to get pre-compilation rules that could show warnings in interactive mode. Maybe this can be a path to dig. :) > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 17, 2017

Lowering the pain of newbies

by Stephane Ducasse

Hi guys my son coded in Pharo 60 testGuessUrlPart |dg8| dg8 := GameItem new; name: 'Dragon Quest VIII : Journey Of The Cursed King'; console: 'PS2'. self assert: dg8 guessUrlPart equals: 'dragonquestviiijourneyofthecursedking' and guess what he broke the system. We should not accept such kind of behavior. name: should not change the name of the class. I do not know the solution but I fear when I will teach 160 students this fall. We should make sure that Pharo is not a system only for experts! any idea is welcome https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-aut… Stef

Aug. 17, 2017

Re: [Pharo-dev] Can we have subclasses of Process?

by Eliot Miranda

Hi Denis, as others have pointed out one can subclass Process. One can also add instance variables to Process. The constraint is that the first four (*) instance variables must be left unaltered. The VM makes use of the first four: Object subclass: #Link instanceVariableNames: 'nextLink' Link subclass: #Process instanceVariableNames: 'suspendedContext priority myList... (*five when we have the multithreaded FFI, the fifth being threadId used to bind processes to specific OS threads when required) The same goes for ProcessorScheduler - the VM uses quiescentProcessLists & activeProcess, and Semaphore - the VM uses firstLink lastLink & excessSignals. On Thu, Aug 17, 2017 at 5:03 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > Is it allowed to subclass Process? I remember that there were some > problems with it but I could not find any information. > > Generally I think about system processes which can be represented by > concrete subclasses. For example explicit UIProcess can be used to remove > many #isUIProcess conditions from system. > > Best regards, > Denis > -- _,,,^..^,,,_ best, Eliot

Aug. 17, 2017

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

by Nicolas Cellier

2017-08-17 20:43 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Stef, > > On Thu, Aug 17, 2017 at 8:08 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> I do not know but I imagine that I added basenameWithoutExtension because >> I found the name much much clearer. I would have never guessed that >> base is the basename without the extension. >> > > While basenameWithoutExtension is an intension revealing selector it is > soon loooonnnnngggg :-) For file manipulation code that's a problem. I > wonder if something like bodyName is better because it's shorter. > > 25 years ago I had `aFilename basename withoutExtension` in my vw app... I don't think that such decomposition is a big efficiency problem for scripting. Nicolas >> Stef >> >> On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >> > Hi All, >> > >> > I've just taken a look at issue 19609 FileReference>>base should be >> > before last separator and wonder whether it is a correct interpretation >> > of the original intentions. >> > >> > The original author of the issue, Michael, seems to feel that >> > FileReferene>>base and FileReference>>basenameWithoutExtension are the >> > same. >> > >> > My reading of the comments is that they perform a different function, >> > i.e.: >> > >> > >> > '/a/b/c.d.e' asFileReference base. "c" >> > '/a/b/c.d.e' asFileReference basenameWithoutExtension. "c.d" >> > >> > >> > are both the expected values, i.e.: >> > >> > - #base answers the name up to the first extensionDelimiter. >> > - #basenameWithoutExtension answers the name without what is typically >> > considered the file extension (the bit after the last >> > extensionDelimiter). >> > >> > Not shown above, but: >> > >> > - #basename answers the entire filename, i.e. "c.d.e". >> > >> > >> > Does anyone know the history of these methods? >> > >> > >> > Cheers, >> > Alistair >> > >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Aug. 17, 2017

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

by Eliot Miranda

Hi Stef, On Thu, Aug 17, 2017 at 8:08 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I do not know but I imagine that I added basenameWithoutExtension because > I found the name much much clearer. I would have never guessed that > base is the basename without the extension. > While basenameWithoutExtension is an intension revealing selector it is soon loooonnnnngggg :-) For file manipulation code that's a problem. I wonder if something like bodyName is better because it's shorter. > Stef > > On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > Hi All, > > > > I've just taken a look at issue 19609 FileReference>>base should be > > before last separator and wonder whether it is a correct interpretation > > of the original intentions. > > > > The original author of the issue, Michael, seems to feel that > > FileReferene>>base and FileReference>>basenameWithoutExtension are the > > same. > > > > My reading of the comments is that they perform a different function, > > i.e.: > > > > > > '/a/b/c.d.e' asFileReference base. "c" > > '/a/b/c.d.e' asFileReference basenameWithoutExtension. "c.d" > > > > > > are both the expected values, i.e.: > > > > - #base answers the name up to the first extensionDelimiter. > > - #basenameWithoutExtension answers the name without what is typically > > considered the file extension (the bit after the last > > extensionDelimiter). > > > > Not shown above, but: > > > > - #basename answers the entire filename, i.e. "c.d.e". > > > > > > Does anyone know the history of these methods? > > > > > > Cheers, > > Alistair > > > > -- _,,,^..^,,,_ best, Eliot

Aug. 17, 2017

Re: [Pharo-dev] [Vm-dev] eventual crashes pharo vm

by Eliot Miranda

Hi Henry, On Wed, Aug 16, 2017 at 9:04 PM, henry <henry(a)callistohouse.club> wrote: > To let you know what I tried, trying to learn about this system as I dig > into it, I added isInteger to the #blockedSelectors of NearERef. This > crashed the squeak vm when I ran the test, and as I look into how > blockedSelectors is used it smashes the resolver. What seems to be needed > is a list of immediateSelectors, though that may grow to be a sizeable > list. This causes me to think there must be a different approach between > async and sync code. > Please wait until mustBeBooleanMagic: is fixed before you write this off. In Squeak what happens if you implement mustBeBoolean to resolve the promise? > > - HH > > > -------- Original Message -------- > Subject: Re: [Vm-dev] [Pharo-dev] eventual crashes pharo vm > Local Time: August 16, 2017 11:46 PM > UTC Time: August 17, 2017 3:46 AM > From: henry(a)callistohouse.club > To: Eliot Miranda <eliot.miranda(a)gmail.com> > Squeak Virtual Machine Development Discussion <vm-dev@lists. > squeakfoundation.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, > Marcus Denker <marcus.denker(a)inria.fr> > > Hi Eliot, > > I have disabled that test for the time being. It will require some deeper > thought regarding immediate selectors, I think, and I am deep into another > area right now. As mustBeBoolean is from inside the VM, a different > approach may be the right solution. A part of me thinks autocoercion > between msg sending (async) and msg calling (sync) is what is needed, but I > want continuation-based VatSemaphores to prevent a liveness lock on the > event loop to support. Again, I have not thought deep enough in this area. > > Thanks again for your help, > > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 16, 2017 10:32 PM > UTC Time: August 17, 2017 2:32 AM > From: eliot.miranda(a)gmail.com > To: henry <henry(a)callistohouse.club> > Marcus Denker <marcus.denker(a)inria.fr>, Pharo Development List < > pharo-dev(a)lists.pharo.org>, Squeak Virtual Machine Development Discussion > <vm-dev(a)lists.squeakfoundation.org> > > Hi Henry, > > On Wed, Aug 16, 2017 at 6:33 PM, henry <henry(a)callistohouse.club> wrote: > >> That is good news, that it is due to this code doing funniness than a VM >> issue. This code trying to bring asynchrony within a synchronous >> environment brings new issues. >> >> What do you think that right solution is to the issue of a call >> expected to be immediate, change out to go eventual until the arguments >> resolve? >> > > I'm not informed enough to know. One could implement mustBeBoolean in the > ERef hierarchy and resolve the promise before going on. One could rely on > the mustBeBooleanMagic: if one wanted a fully lazy system. I don't know > the trade-offs between the two. I do know that while the > miustBeBooleanMagic: solution is cool and fun it is extremely slow. So if > performance is an issue use the first approach. > > > >> How can it be structured correctly on the stack without generic >> functions? I think with the double dispatch of an eventual but I have not >> spend much time in this particular area. >> > > Yes that's an issue There is already a problem with #==. It needs to be > symmetric for correctness. > > >> Preventing the vm from crashing would be a good interim step but even >> here I am not sure how to go about crafting a solution. >> > > Well, the issue is simply that the wrong pc is chosen for the continuation > after the mustBeBoolean. I'm sure the right answer is straight-forward to > obtain. > > > >> Thank you for investigating this. >> > > You're welcome. > > >> >> >> - HH >> >> >> On Wed, Aug 16, 2017 at 20:46, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >> Hi Henry, Hi Marcus, >> >> On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: >> >> Hi all. I was testing with this eventual_test package and it blows up the >>> pharo 6.1 vm. I'd welcome pointers >>> >>> http://www.squeaksource.com/TurquoiseTesting.html >>> >>> - HH >>> >> >> I took a look at this and I think you've found a bug in the >> mustBeBooleanMagic: code. What's happening is a mustBeBoolean in >> Integer>>* due to evaluating >> 10 * 42 eventual >> in RefsTest>>testFailureArithmeticPrimitivesWithPromiseArgument >> >> Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and >> does ^super * anInteger (where anInteger is the NearERef). So that >> evaluates Integer>>* >> >> Integer>>* aNumber >> "Refer to the comment in Number * " >> aNumber isInteger ifTrue: >> [^ self digitMultiply: aNumber >> neg: self negative ~~ aNumber negative]. >> ^ aNumber adaptToInteger: self andSend: #* >> >> aNumber, being a NearERef, answers a PromiseERef for the isInteger send, >> and this provokes a mustBeBoolean for the isInteger ifTrue: [... >> >> After the mustBeBooleanMagic: the stack looks wrong. The activation of >> Integer>>*, which is about to do >> ^ aNumber adaptToInteger: self andSend: #* >> does not have enough items on the stack. Instead of containing >> a NearERef (for 42) >> 10 >> #* >> it contains >> a PromiseERef (for 42 eventual isInteger) >> >> and the send of #adaptToInteger:andSend: ends up taking more form the >> stack than the VM can handle and it crashes. The bug appears to be with >> the use of sendNode irInstruction nextBytecodeOffsetAfterJump in >> Object>>mustBeBooleanMagic: since execution should resume at bytecode 55 >> below, but does so at bytecode 57 >> >> >> 41 <10> pushTemp: 0 >> 42 <D0> send: isInteger >> 43 <AC 09> jumpFalse: 54 >> 45 <70> self >> 46 <10> pushTemp: 0 >> 47 <70> self >> 48 <D1> send: negative >> 49 <10> pushTemp: 0 >> 50 <D1> send: negative >> 51 <E2> send: ~~ >> 52 <F3> send: digitMultiply:neg: >> 53 <7C> returnTop >> 54 <10> pushTemp: 0 >> 55 <70> self >> 56 <24> pushConstant: #* >> 57 <F5> send: adaptToInteger:andSend: >> 58 <7C> returnTop >> >> So the positioning of the context's pc must be before any argument >> marshaling for the next send, not simply the send itself. >> >> Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add >> initlaPC and resumePC temporaries at the beginning and capture them via >> initialPC := context pc. >> at the beginning and then >> context pc: (resumePC := sendNode irInstruction >> nextBytecodeOffsetAfterJump) >> to see what I'm seeing. >> >> >> Phew. Glad it's not a VM bug :-) >> >> HTH >> _,,,^..^,,,_ >> best, Eliot >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > > > > -- _,,,^..^,,,_ best, Eliot

Aug. 17, 2017

Re: [Pharo-dev] Adding build info into pharo runtime

by Torsten Bergmann

Aug. 17, 2017

Re: [Pharo-dev] ZnEasy question

by Sven Van Caekenberghe

Hi Milton, > On 5 Aug 2017, at 03:15, milton mamani <akevalion(a)gmail.com> wrote: > > Hi to all > > I want to use the next instruction in my code > > response := ZnEasy get: 'https://archive.softwareheritage.org/api/1/origin/git/url/https://github.co…'. > response. > > The previous code works from command line or in a webbrowser, but I does not work with ZnEasy > Because it takes the previous link as: > a ZnRequest(GET /api/1/origin/git/url/https:/github.com/hylang/hy) > > Could you please tell me what can I do for this situation? > > Cheers, > Milton ZnUrl has indeed a problem parsing this URL. It skips empty path segments, we'll have to create an issue for that and we should try to fix it, maintaining current behaviour. The parser is hand written and has evolved a bit over the years, so it is a bit brittle. Seaside's WAUrl seems to have the same problem. It is funny that this only now comes up. Thanks for reporting it. Here is a workaround, by manually creating a ZnUrl object from its elementary components. ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); yourself. You can use this as follows. ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); retrieveContents. ZnEasy get: (ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); yourself). Regards, Sven

Aug. 17, 2017

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

by Esteban Lorenzano

> On 17 Aug 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On Thu, Aug 17, 2017 at 11:54:57AM +0200, Pavel Krivanek wrote: >> >> >> 2017-08-17 10:44 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: >> >> Hi, >> >> even when contributing to Pharo 7.0 is still very very cumbersome I was >> able >> to sort out most of the problems and contribute already a few smaller >> things. >> >> Unfortunately there is not much communication on what is currently in the >> pipe >> or planned on easing the process - which can easily lead to the impression >> that we do not really move or slow us down. >> >> I know step by step it goes and at least we have again the build process >> rolling >> https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is- >> starting-to-roll-for-real/ >> >> Nonetheless one of my PRs was already integrated and the integration of my >> WebBrowser >> package is still in the pipe (https://github.com/pharo-project/pharo/pull/ >> 193) >> >> The descriptions from Guille helped me - but there are still things I need >> answers to: >> >> 1. Will or is it still possible to automatically update" an image in Pharo >> 7 >> or in the future? >> The World menu entry "System" -> "System update" has been removed? >> >> Is this temporary of will it return once we know how it could be done >> again? >> >> >> You can update your image in Iceberg by switching to the updated #development >> branch and then to reload all packages. In most cases it will probably work >> fine but it does not know the right packages loading order, does not know >> changes in the packages structure etc. >> And some updates cannot be done at all (e.g. https://github.com/pharo-project/ >> pharo/pull/205). So you can expect troubles. >> With Cargo we can get smoother updating process but trying to maintain it now >> would be IMHO waste of resources. >> >> -- Pavel > > If the order is important... > > Iceberg models the commits, so it should be possible to start at the > head and trace back to the commit used to build the image. The > resulting list of commits could then be loaded in the correct order. > (I don't know if this would help in the case of PR #205) hehâ¦ no. Order of commits has nothing to do with order of loading packages. also: - class initialization has to happen - migrate changed instances needs to be prepared pre and post change. while most of the time update packages âjust worksâ, the case of slots for example will not work no matter the loading order, because we need to ensure some pre actions and post actions to happen. Iâm playing with the idea to extend iceberg with the capability of processing some information at package and class level (in package with manifests and in classes with class methods). Like adding #iceLoad, #iceUpdate methods (or #iceUpdateBefore and #iceUpdateAfter) so we can handle thisâ¦ but this will not happen immediately (in case we decide it worths to have it) :) > > Just to add a positive note to the conversation: I'm not very > knowledgable about git, but it seems to be the best source control tool > by far (based on my limited experience), and I've seen steady > improvement in Iceberg since Esteban indicated that it would be the > basis of source control for Pharo. What I've seen so far makes me think > that we are going down a good path, even if it is taking longer we would > like and is causing some pain along the way. nice! and yes, this kind of changes take a lot of timeâ¦ we are always too optimists and when we said âat least 3 monthsâ we should have said double that timeâ¦ but Iâm happy with things as they are starting to fit. And in a couple of months we will be a full speed :) cheers! Esteban > > > Cheers, > Alistair >

Aug. 17, 2017