- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] A problem with latest image (64bit) ? (Please confirm)

by Max Leske

I've been seeing this in the early Pharo 7 builds. But it didn't occur with latest VM's, only with SmalltalkCI, so I ignored it. On 15 Jan 2019, at 12:30, Esteban Lorenzano wrote: > Hello, > > Iâm experiencing a problem with latest image (and latest vm) in Mac > (Mojave). > After doing > > Stdio stdout << âOKâ > > Iâm having this stack: > > File class(ProtoObject)>>primitiveFailed: > File class(ProtoObject)>>primitiveFailed > File class>>fileDescriptorType: > File class>>fileDescriptorIsAvailable: > Stdio class>>standardIOStreamNamed:forWrite: > Stdio class>>stdout > UndefinedObject>>DoIt > OpalCompiler>>evaluate > RubSmalltalkEditor>>evaluate:andDo: > RubSmalltalkEditor>>highlightEvaluateAndDo: > GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>popupPrint > MorphicAlarm(MessageSend)>>value > MorphicAlarm>>value: > WorldState>>triggerAlarmsBefore: > WorldState>>runLocalStepMethodsIn: > WorldState>>runStepMethodsIn: > WorldMorph>>runStepMethods > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > [ [ WorldMorph doOneCycle. > Processor yield. > false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in > Block: [ [ WorldMorph doOneCycle.... > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess in Block: [ > self value.... > > Con someone confirm or refute this? > > Thanks! > Esteban

Jan. 15, 2019

Re: [Pharo-dev] A problem with latest image (64bit) ? (Please confirm)

by Gabriel Cotelli

At least on Linux (with the latest VM and image downloaded for zero conf) it's working fine. Image ----- Pharo7.0.0rc1 Build information: Pharo-7.0.0+rc1.build.121.sha.0640e0d300e69541033fb1c4270c9b0d7d401b01 (64 Bit) Unnamed Virtual Machine --------------- pharo-vm/lib/pharo/5.0-201901100922/pharo CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 10 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 10 2019 VM: 201901100922 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jan 10 10:22:25 2019 CommitHash: 58ffe032 Plugins: 201901100922 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Unix built on Jan 10 2019 09:32:18 Compiler: 4.8.4 VMMaker versionString VM: 201901100922 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jan 10 10:22:25 2019 CommitHash: 58ffe032 Plugins: 201901100922 https://github.com/OpenSmalltalk/opensmalltalk-vm.git CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 10 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 10 2019 Operating System/Hardware ------------------------- unix linux-gnu x86_64 On Tue, Jan 15, 2019 at 8:31 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hello, > > Iâm experiencing a problem with latest image (and latest vm) in Mac > (Mojave). > After doing > > Stdio stdout << âOKâ > > Iâm having this stack: > > File class(ProtoObject)>>primitiveFailed: > File class(ProtoObject)>>primitiveFailed > File class>>fileDescriptorType: > File class>>fileDescriptorIsAvailable: > Stdio class>>standardIOStreamNamed:forWrite: > Stdio class>>stdout > UndefinedObject>>DoIt > OpalCompiler>>evaluate > RubSmalltalkEditor>>evaluate:andDo: > RubSmalltalkEditor>>highlightEvaluateAndDo: > GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>popupPrint > MorphicAlarm(MessageSend)>>value > MorphicAlarm>>value: > WorldState>>triggerAlarmsBefore: > WorldState>>runLocalStepMethodsIn: > WorldState>>runStepMethodsIn: > WorldMorph>>runStepMethods > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > [ [ WorldMorph doOneCycle. > Processor yield. > false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: > [ [ WorldMorph doOneCycle.... > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self > value.... > > Con someone confirm or refute this? > > Thanks! > Esteban >

Jan. 15, 2019

A problem with latest image (64bit) ? (Please confirm)

by Esteban Lorenzano

Hello, Iâm experiencing a problem with latest image (and latest vm) in Mac (Mojave). After doing Stdio stdout << âOKâ Iâm having this stack: File class(ProtoObject)>>primitiveFailed: File class(ProtoObject)>>primitiveFailed File class>>fileDescriptorType: File class>>fileDescriptorIsAvailable: Stdio class>>standardIOStreamNamed:forWrite: Stdio class>>stdout UndefinedObject>>DoIt OpalCompiler>>evaluate RubSmalltalkEditor>>evaluate:andDo: RubSmalltalkEditor>>highlightEvaluateAndDo: GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>popupPrint MorphicAlarm(MessageSend)>>value MorphicAlarm>>value: WorldState>>triggerAlarmsBefore: WorldState>>runLocalStepMethodsIn: WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle WorldMorph class>>doOneCycle [ [ WorldMorph doOneCycle. Processor yield. false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: [ [ WorldMorph doOneCycle.... [ self value. Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value.... Con someone confirm or refute this? Thanks! Esteban

Jan. 15, 2019

Re: [Pharo-dev] Availability of Smallapack in Pharo6.0

by StÃ©phane Ducasse

> > Hi Denis, > OK, but hiding is troubling... > When I came from VW, I found that Squeak categories matching package names was a quick and dirty hack. > Since then, I find it works remarkably well, it is somehow a declarative meta information (method property), and I much prefer that to hidden package classification accessible from an IDE only. I agree :) and I told that several times in the past :) We also lost the inplace edit and the logic sometimes is super confusing. > It still happens to me to loose methods in VW because they are not packaged or wrongly packaged, so I'm not sure that cleaning is winning in that case. > And if you go with multiple classifications, then there's no reason to not keep the hack. For now multiple classifications is not in our priority since our list is already too long. > > But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Jan. 14, 2019

About resurrecting the RE package and plugin

by ducasse

Hi I would really like to resurrect the REPlugin and its image side abstraction because I think that this is important to support Perl level regex since it will help people to reuse their knowledge. If you are interested in helping let us know. Stef

Jan. 14, 2019

Re: [Pharo-dev] [ANN] New stable VMs promoted

by Tudor Girba

Great. Thanks! Doru -- www.tudorgirba.com "Every thing has its own flow" > On 14 Jan 2019, at 14:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I just promoted the VM: > > 201901051900-7a3c6b6 > > (From Jan/05) > > As stable VMs for all platforms. > > Enjoyâ¦ and please report any problems ! > > Esteban

Jan. 14, 2019

[ANN] New stable VMs promoted

by Esteban Lorenzano

Hi, I just promoted the VM: 201901051900-7a3c6b6 (From Jan/05) As stable VMs for all platforms. Enjoyâ¦ and please report any problems ! Esteban

Jan. 14, 2019

Re: [Pharo-dev] FFILibrary uniqueInstance

by Ben Coman

On Mon, 14 Jan 2019 at 17:12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > On 14 Jan 2019, at 09:46, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi Nicolas, > On Fri, Jan 11, 2019 at 12:09 PM Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Hi all, >> I wanted to know if the moduleName was cached somewhere or recomputed at >> each function call... >> It seems to be recomputed. >> > > Do you mean when using a symbol/string as module like...? > > ioFindSurface: id dispatch: dispPtr handle: handlePtr > self ffiCall: #( bool ioFindSurface(int id, void * dispPtr, int > *handlePtr) ) module: #SurfacePlugin > > >> >> We could have a different scheme: >> moduleName is cached in a class inst var of FFILibrary. >> FFILibrary is then added to startup list and moduleName is reset when >> resuming on a different platform. >> instance side moduleName calls class side moduleName. >> >> Or moduleName becomes an inst var, set during uniqueInstance >> construction, and uniqueInstance is nilled out when resuming. >> >> What do you think? >> > > As I see it, there are two (basic) schemas to do FFI calls using UFFI > - using a library object. Library objects are actual singletons stored in > class instance variables > > FFILibrary class >> uniqueInstance > self = FFILibrary > ifTrue: [ self error: 'I''m an abstract class, use one of my children.' ]. > ^ uniqueInstance ifNil: [ uniqueInstance := super new ] > > - using a symbol/string, then a module is created dynamically > > String >> asFFILibrary > ^ FFIUnknownLibrary name: self > > But, but :) the thing is that ffi calls in UFFI are lazily compiled using > bytecode transformations and there (if I'm not mistaken) the library > instances created are cached on the callout object stored as a literal in > the method. > So there is a cache, but per ffi call. And then, at shutdown, all the > generated methods (bound to a specific external function) are wiped out. > > All this process is of course perfectible and probably a "coup de" > profiling could be nice ^^. > > > Well, when I designed the FFILibrary I first thought: letâs the user > decide if they want to cache or not (because most of the time is not > worthy, since as Guille says it is cached on each method and usually is > straightforward) > Then I thought that maybe I should add a generic cache mechanism, for > those cases where you need to perform complicated locates. But I did not > had the time to do it. > > So, I would say: yes, it would be good to have a cache mechanism, but most > of the time is not needed (and caches are dangerous things so better to > reduce their usage at max). > One thing that was get easily confusing is when when the moduleName is not found it seems to cache that error, so that even when the C-library is installed into the correct location it continues to not find the function. I should have added this to the bug tracker a while ago, but I haven't checked for a while so I don't know if this is still the case. I'll wait your response and if agreeable I'll add it to the P8 bug tracker. cheers -ben > If someone wants to implement that for their library, they can. > If someone wants to implement a generic mechanism and contribute it, it > would be also welcomed :) > > Esteban > > > > HTH, > Guille > > >

Jan. 14, 2019

Re: [Pharo-dev] FFILibrary uniqueInstance

by ducasse

Esteban Do you know if this points is documented in the FFILibrary class comments? Can you add a bug entry so that we do not forget? TX Stef > On 14 Jan 2019, at 10:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > >> On 14 Jan 2019, at 09:46, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Hi Nicolas, >> On Fri, Jan 11, 2019 at 12:09 PM Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >> Hi all, >> I wanted to know if the moduleName was cached somewhere or recomputed at each function call... >> It seems to be recomputed. >> >> Do you mean when using a symbol/string as module like...? >> >> ioFindSurface: id dispatch: dispPtr handle: handlePtr >> self ffiCall: #( bool ioFindSurface(int id, void * dispPtr, int *handlePtr) ) module: #SurfacePlugin >> >> >> We could have a different scheme: >> moduleName is cached in a class inst var of FFILibrary. >> FFILibrary is then added to startup list and moduleName is reset when resuming on a different platform. >> instance side moduleName calls class side moduleName. >> >> Or moduleName becomes an inst var, set during uniqueInstance construction, and uniqueInstance is nilled out when resuming. >> >> What do you think? >> >> As I see it, there are two (basic) schemas to do FFI calls using UFFI >> - using a library object. Library objects are actual singletons stored in class instance variables >> >> FFILibrary class >> uniqueInstance >> self = FFILibrary >> ifTrue: [ self error: 'I''m an abstract class, use one of my children.' ]. >> ^ uniqueInstance ifNil: [ uniqueInstance := super new ] >> >> - using a symbol/string, then a module is created dynamically >> >> String >> asFFILibrary >> ^ FFIUnknownLibrary name: self >> >> But, but :) the thing is that ffi calls in UFFI are lazily compiled using bytecode transformations and there (if I'm not mistaken) the library instances created are cached on the callout object stored as a literal in the method. >> So there is a cache, but per ffi call. And then, at shutdown, all the generated methods (bound to a specific external function) are wiped out. >> >> All this process is of course perfectible and probably a "coup de" profiling could be nice ^^. > > Well, when I designed the FFILibrary I first thought: letâs the user decide if they want to cache or not (because most of the time is not worthy, since as Guille says it is cached on each method and usually is straightforward) > Then I thought that maybe I should add a generic cache mechanism, for those cases where you need to perform complicated locates. But I did not had the time to do it. > > So, I would say: yes, it would be good to have a cache mechanism, but most of the time is not needed (and caches are dangerous things so better to reduce their usage at max). > If someone wants to implement that for their library, they can. > If someone wants to implement a generic mechanism and contribute it, it would be also welcomed :) > > Esteban > > >> >> HTH, >> Guille

Jan. 14, 2019

Re: [Pharo-dev] Development process: testing the GUI

by ducasse

Yes we would love that. Now for P8 we are revisiting all Spec code and improving improving improving. But Spec is not at the level of UI but UI Model. Still it would be really nice to have tests at this level to start. Stef > On 13 Jan 2019, at 21:34, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Sure, it will require more uniform API. > Elm has an advantage with static typing, but I'm sure we can do without it. > Maybe this should be integrated in the requirements/objectives of next frameworks. > > Le dim. 13 janv. 2019 Ã 10:53, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : > Hi, > > Wellâ¦ we âplanâ to have tests also on UI. > But this is hard. > And not just because of the tooling, but also because having a coherent metaphor to organise everything is hard. > We are working (very slowly) in that direction. > And eventually, we would like to have also UI tests. > > Esteban > > >> On 12 Jan 2019, at 23:34, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >> >> Hi all, >> Pharo team is attaching great care in securing and improving the development process, notably by promoting usage of tests and continuous integration. >> >> I think a very good job is already done in the libraries provided by Pharo. But sometimes I encounter more hickups with the development tools themselves. >> So I wonder: does this apply to the GUI yet? >> This is a difficult area, but nowadays this exists elsewhere. >> For example, with Elm and Elmer (https://medium.com/@brian.watkins/test-driving-elm-with-elmer-649e2e7e02a8 <https://medium.com/@brian.watkins/test-driving-elm-with-elmer-649e2e7e02a8>), TDD can be applied on UI, providing both a formal specification and non regression tests. >> Do we have something similar? >> Don't we wish having something similar? >

Jan. 14, 2019