January 2019 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] FFILibrary uniqueInstance

by Esteban Lorenzano

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 <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] FFILibrary uniqueInstance

by Guillermo Polito

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 ^^. HTH, Guille

Jan. 14, 2019

Some clarifications (was DebugSession>>activePC:)

by ducasse

Hi Eliot I would like to make some clarifications. Preamble: -------------- I was thinking that I should not reply but I think that I have the right to clarify a bit because I do not like several points. I reply as Stef "the guy that had the vision of Pharo and that spent 10 years pushing and building Pharo.â So I think that it makes me credible enough. My points: ------------- - With you this is always the same: Iâm too emotional and it ends everything. Stephane is emotional so we cannot communicate with him. You often place yourself as a professional and that Iâm emotional. Could you stop this little game because to me it starts to be a bit boring? Or I will just put a filter and trash systematically your emails. - Last week you told us that time bombing our process was a bad idea in an answer about settings keeping references instead of releasing them. First this had nothing to do with the problem. You see P7 was delayed because we considered that the system was not ready but P7 should be released. May I make the remark that the world is using time-based delivery? - About CMake, you may be right that makefile is better than CMake but a part of the world is using CMake and the net result is that we lost our effort and infrastructure just to follow you. Ronie uses CMake. Igor which I consider as a talented developer used CMake because he thought it was the best tool he should use. - About infrastructure and process. I wanted to check the REplugin this week end because we should use it since the world is using Perl reg-expression and I could not find the code of the plugin on github. I saw that some plugin code is not even versioned and only available on a strange ftp and it was surprising to me. Iâm still surprised that after 3 years (when esteban requested that all plugin code are grouped together in a single place, this is still not the case). - Did it not look strange to you that Esteban left the VM list in the past? Esteban looks like a reasonable and stable person to me. - You are systematically telling to me that Iâm offended when people criticized us. Iâm not offended by critics. We are not offended by critics. We have internal emails that are much more violent about our own process. We are not blind and we reflect on our own process and we invite people to REPORT problems. Now we ask people to be credible when they do it because we are busy - report situation - step by step reproducibility - proportionality of the voice versus the problem - and not been offensive We did not see any official reports about problems that we may have introduced. - You are vocal about âinstability". And you report that one method changed. Seriously? Are you not exagerating a bit? Let us talk about instability: - When we talk about instability we talk about the fact that we cannot use for real ephemerons because they corrupt the memory and that we get random crash. - We had instability when we have memory leaks that randomly slows down Pharo. - We had instability which delays our release with a bug in FFI that made cairo crash on windows 64 bits. If you want to interact with us (and not only me, because Iâm the tip of the iceberg and many people are frustrated by your attitude), let us start with positive communication and attitude: - You express your problems and we see how we (together) can fix them. - You can contribute by writing tests and by entering bug entries in the bug tracker. About Pharo: ââââââââ We understand that some people do not like it but we do not force anybody use and make business with it. Now I want to make something super clear: Pharo will not sacrifice agility and improvements on the altar of compatibility with Squeak. Pharo will change because Pharo is agile and because many things should be improved. We pay real attention about backwards compatibility. Much more than people think. Because we have many external projects and libraries that we support. Now if Pharo is used to build the VM then we will have to find a way to pay attention. And we will reinvest in building a process that checks this. Our problem is that integration time cannot take hours and right now validating Pharo is a bit too long. We will work on it. We strongly advocate to invest in tests. Tests are a good mechanisms to support evolution. If you have tests we can automatically rewrite deprecated methods and we will use this more often. We finally start to have: - a better compiler and not an ancient one which reported error as Morph. - a better architecture, more modular - a real bootstrap (we should improve it and build tools to support it - we are working on it) - strong libraries (File, Stream, HTTP) more documented and tested - better tools (Iceberg and Calypso are definitively steps in the right direction) And we will continue to improve. We will iterate on all these to make Pharo even better. We are writing more tests to support those changes. I repeat it: I think that we are doing a pretty good job about the quality that we deliver. Stef > On 11 Jan 2019, at 18:54, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Stef, > >> On Jan 10, 2019, at 7:59 AM, ducasse <stepharo(a)netcourrier.com> wrote: >> >> Eliot I would like also two points to this. >> >> - First we asked thomas to write tests about the debugger model and you see if they would be tests about methods we could understand >> that they are used and control what they do. So we should all thank thomas for his energy in this not so easy task. >> >> - Second it would be nice if you could refrain to be systematically negative about what we are doing. I think that our development process >> is much better than many others :) It is not perfect because this does not exist. >> I think that we are doing a great job make Smalltalk cool. And yes it may happen that one untested, undocumented method >> get lost. I think that we are doing pretty good given the resources we have. > > Even more serious an issue for the Pharo community than a development process which fails to support the Nedâs of users is a defensive attitude that does not want to discuss serious issues maturely. I bring up the stability and backward-portability issue because it is *important*; it has affected ClÃ©mentâs ability to deliver Sista and my and feenkâs efforts to support VM development on Pharo. If your response to my trying to discuss seriously and objectively a problem that needs discussion is always to say âplease donât be negativeâ I have even less confidence that Pharo can be a realistic platform for my work and the work of others. > > >> Stef >> >>> On 10 Jan 2019, at 15:11, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi Thomas, >>> >>>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>>> >>>> <mime-attachment> >>> >>> in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc. >>> >>> Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al. >>> >>> So the distinction is important and the utility method is probably useful. >>> >>> Do you want to remove the method simply because there are no senders in the image? >>> >>> If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed. >>> >>> Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable. >> >> >>

Jan. 14, 2019

Esteban's ChangeLog week of 7 January 2019

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 7 January 2019 to 13 January 2019. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=7/1/2019&to=13/1/2019 ChangeLog ========= 11 January 2019: ---------------- * Finally fixed bootstrap issues related to Pharo8.0 development. Now we are ready to go :) Issues fixed: * [https://github.com/pharo-project/pharo/pull/2214](https://github.com/pharo-… * [https://github.com/pharo-project/pharo/issues/2212](https://github.com/phar… * [https://github.com/pharo-project/pharo/issues/2129](https://github.com/phar… * [https://github.com/pharo-project/pharo/issues/2211](https://github.com/phar… * [https://github.com/pharo-project/pharo/issues/2130](https://github.com/phar… 9 January 2019: --------------- * I've been working on release Pharo7.0 as soon as possible. For that, Pharo8.0 development needs to be in place and there were some errors on the bootstrap. I'm working on those: * [2129](https://github.com/pharo-project/pharo/issues/2129) * [2130](https://github.com/pharo-project/pharo/issues/2130) Both are kind of related, since it depends on how to take correctly the working branch. Anyway... not finished, but almost :) cheers! Esteban

Jan. 14, 2019

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

by Nicolas Cellier

Le sam. 12 janv. 2019 Ã 14:14, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > Hi Nicolas > > Ð¿Ñ, 11 ÑÐ½Ð². 2019 Ð³. Ð² 23:34, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > >> Hi, >> I announce the availability of Smallapack in Pharo6. >> >> The ConfigurationOfSmallapack is in >> http://www.squeaksource.com/MetacelloRepository and there is a copy in >> meta repo for Pharo 3/4/5/6. >> >> Currently, the ported version uses a derivative of OpalCompiler patched >> to handle method with 16+ arguments. >> External function calls have not been converted yet to UnifiedFFI, but >> the patched compiler rather has hook to compile legacy FFI. >> Though I did not install the hook to call FFI with more than 15 >> arguments, so there is at least 1 unit test failing (but not crashing). >> >> I have auto-re-generated all the source code for using UnifiedFFI >> formats, so the dependency on legacy FFI is not a necessity (apart for >> simplifying cross dialect maintenance). >> >> But I want to review the generated code method by method rather than >> filing it in blindly (the wrapper functions are also generated, and I might >> loose comments or improvments if I'm careless). Unfortunately, the state of >> diff tools in Pharo6, be it thru MC or worse than all, thru legacy change >> lists, does not enable such a large scale review, so I think that I will >> edit in Squeak and run in Pharo... >> >> Now that Smallapack supports Opal, there should be no major problem for >> porting to Pharo7, but I did not have time to try yet. A few more MC >> regressions, and the fact to forbid protocol beginning with a * was too >> serious a cross compatibility hurdle for me. >> > > Protocol with star is still convention to store class extensions in files. > No compatibility issues here. Calypso just hides it from user because > package and protocol is not the same thing. And I hope in Pharo 8 we will > support multiple protocols and separate packaging. But more important is to > finely clean RPackage implementation. The current way how method is became > bound to package is horrible. > > 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. 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. But I'll come back to it, tools are generally better in ph7 than ph6. Stay >> tuned. >> >>

Jan. 13, 2019