- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] VirtualMachine vs. Platform and Bootstrap

by Ben Coman

On 19 February 2018 at 17:35, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Fri, Feb 16, 2018 at 10:18 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi, >> >> 1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit >> (internally depending on wordSize): >> >> Smalltalk vm is32Bit >> >> Anything OK on that side. >> >> 2. We can also query for the OPERATING SYSTEM we are running on using: >> >> Smalltalk os >> >> and there are subclasses for OSPlatform like Win32Platform, >> Win64Platform as well as Unix32Platform, >> unix64Platform, ... >> >> But when I evaluate "Smalltalk os" in Pharo 7 Build #70552 >> >> 2a) I receive a Win32Platform instance which means 32 bit although >> I'm running on a Win 64 system >> 2b) I receive a Unix32Platform instance which means 32 bit although >> I'm running on a Ubuntu 64 system >> >> I see this as a clear bug and very confusing >> > > Yup. > > >> >> The reason for this behavior is simple: because I run with the 32 bit >> VM/image on these two 64 bit operating >> systems and in Pharo: >> >> for 2a) the#isActivePlatform method ask the VM (???)for the platform >> name (which is Win32 then) >> >> for 2b) the#isActivePlatform method also considers the word size from >> the VM (???) >> >> But to me the "os" should give me infos about the underlying operating >> system and is currently >> returning a wrong instance (because it falls back to querying about the >> running VM, not the real platform) >> > Good point, but to be pedantic I'd say "not the real OS" rather than "not the real platform". Would it be correct to distinguish between OS and Platform? where Platform is your compile target, and OS is where you run the exe ?? Thus the fix would not be just for "Smalltalk os" ==> Win64Platform but to introduce "Smalltalk platform" ==> Win64Platform for 64 bit VM and ==> Win32Platform for 32 bit VM. and "Smalltalk os" ==> something else entirely. or maybe I'm completely off base. cheers -ben > >> This would be easy to fix with some UFFI calls (for instance piping from >> "uname -i" on Unix or "ver" on Windows). >> With UFFI I would also be able to give more and better infos in the >> platform hierarchy about the underlying OS. >> >> But doing this would introduce a dependency from the "Systems-Platforms" >> package to "UFFI" (and currently my >> understanding is that UFFI comes later) >> >> From what I understood from the comment in getPwdViaFFI:with we also >> would like to focus on a minimal dependency >> for bootstrap ... and only depend on FFI and not UFFI. >> > > Well, but that's because the working directory is needed at bootstrap > time. Take into account that the packages that belong to the bootstrap are > those listed in > > BaselineOfPharoBootstrap > > System-Platforms is listed there, but maybe it is not so necessary? We > should check what are the usages of it. > In any case, what I'd say is that "stuff" that is not really needed at > bootstrap time should be loaded afterwards, maybe as a separate package > with extension methods? > And in that case you're free to go and use uFFI, that should be no problem. > > Just take into account that uFFI is loaded by BaselineOfMorphicCore > nowadays. > > >> >> Any comments how we could deal with that best? >> >> Thx >> T. >> >> >> >> >> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Feb. 19, 2018

Re: [Pharo-dev] VirtualMachine vs. Platform and Bootstrap

by Guillermo Polito

On Fri, Feb 16, 2018 at 10:18 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > 1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit > (internally depending on wordSize): > > Smalltalk vm is32Bit > > Anything OK on that side. > > 2. We can also query for the OPERATING SYSTEM we are running on using: > > Smalltalk os > > and there are subclasses for OSPlatform like Win32Platform, > Win64Platform as well as Unix32Platform, > unix64Platform, ... > > But when I evaluate "Smalltalk os" in Pharo 7 Build #70552 > > 2a) I receive a Win32Platform instance which means 32 bit although > I'm running on a Win 64 system > 2b) I receive a Unix32Platform instance which means 32 bit although > I'm running on a Ubuntu 64 system > > I see this as a clear bug and very confusing > Yup. > > The reason for this behavior is simple: because I run with the 32 bit > VM/image on these two 64 bit operating > systems and in Pharo: > > for 2a) the#isActivePlatform method ask the VM (???)for the platform > name (which is Win32 then) > > for 2b) the#isActivePlatform method also considers the word size from > the VM (???) > > But to me the "os" should give me infos about the underlying operating > system and is currently > returning a wrong instance (because it falls back to querying about the > running VM, not the real platform) > > This would be easy to fix with some UFFI calls (for instance piping from > "uname -i" on Unix or "ver" on Windows). > With UFFI I would also be able to give more and better infos in the > platform hierarchy about the underlying OS. > > But doing this would introduce a dependency from the "Systems-Platforms" > package to "UFFI" (and currently my > understanding is that UFFI comes later) > > From what I understood from the comment in getPwdViaFFI:with we also would > like to focus on a minimal dependency > for bootstrap ... and only depend on FFI and not UFFI. > Well, but that's because the working directory is needed at bootstrap time. Take into account that the packages that belong to the bootstrap are those listed in BaselineOfPharoBootstrap System-Platforms is listed there, but maybe it is not so necessary? We should check what are the usages of it. In any case, what I'd say is that "stuff" that is not really needed at bootstrap time should be loaded afterwards, maybe as a separate package with extension methods? And in that case you're free to go and use uFFI, that should be no problem. Just take into account that uFFI is loaded by BaselineOfMorphicCore nowadays. > > Any comments how we could deal with that best? > > Thx > T. > > > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 19, 2018

Re: [Pharo-dev] NeoCSV nil-Handling

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > What do you think ? Could #emptyFieldValue: accept a block instead of the actual value? Or be per-field? Or both? Then the default could still be set via the current mechanism, keeping the usual API simple, but the user would have a bit more control. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 19, 2018

Re: [Pharo-dev] Problem to save packages

by Stephan Eggermont

Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > These are my files, I want to be in control and manage them by myself. > Eventually save them on another medium, and not mix them with thousands of > other files that generally populate a package-cache. > Do you see what I mean? Two aspects: 1 It sounds like you have a shared package cache for all your images? That is somewhat incompatible with the current tooling, especially with regard to reproducible loading of Metacello configurations. Having lots of duplicated mcz's in each image's package cache is wasteful 2 Yes, having much more control over the package cache makes sense, especially with TelePharo. Different scenario's need different strategies. Mixing new, own code with loaded frameworks is not very practical Stephan

Feb. 18, 2018

Re: [Pharo-dev] Problem to save packages

by Nicolas Cellier

2018-02-18 22:01 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > But whatever the bug, why saving in the package-cache? > > The package-cache is just a cache as the name tells. > > It's less volatile than RAM, but can still be subject to aggressive > cleanup. > > Because it is much more reliable than network, and it depends on simpler > and working infrastructure. The package cache is deliberately not cleaned, > and not shared by default. > > Stephan > > > If it would be me, I would then go for my own MCDirectoryRepository. These are my files, I want to be in control and manage them by myself. Eventually save them on another medium, and not mix them with thousands of other files that generally populate a package-cache. Do you see what I mean?

Feb. 18, 2018

Re: [Pharo-dev] Problem to save packages

by Stephan Eggermont

Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > But whatever the bug, why saving in the package-cache? > The package-cache is just a cache as the name tells. > It's less volatile than RAM, but can still be subject to aggressive cleanup. Because it is much more reliable than network, and it depends on simpler and working infrastructure. The package cache is deliberately not cleaned, and not shared by default. Stephan

Feb. 18, 2018

Re: [Pharo-dev] Problem to save packages

by Nicolas Cellier

But whatever the bug, why saving in the package-cache? The package-cache is just a cache as the name tells. It's less volatile than RAM, but can still be subject to aggressive cleanup. Le 18 fÃ©vr. 2018 18:15, "Stephane Ducasse" <stepharo.self(a)gmail.com> a Ã©crit : > Hi vincent > > Welcome to Pharo. > - Did you check that you can write in your cache folder? > - Is there any files in your cache? > - Normally just selecting a package and pressing save should save it. > - The exception you report is super strange. > > Stef > > On Sun, Feb 18, 2018 at 4:39 PM, Roca Vincent <vincentroca9(a)gmail.com> > wrote: > > Hi, > > I'm a new Pharo user (Pharo 5.0). I have created a package and now I just > > want to save it in the package-cache folder. But, when I try to do this > > using the Monticello Browser, I get an exception telling me the file I'm > > trying to save does not exist. I already managed to save some packages > but I > > can't anymore. Thanks in advance for your help. > >

Feb. 18, 2018

[Pharo 7.0-dev] Build #573: 21363-coreMethodsForClass-send-but-not-implemented

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #573 was: SUCCESS. The Pull Request #913 was integrated: "21363-coreMethodsForClass-send-but-not-implemented" Pull request url: https://github.com/pharo-project/pharo/pull/913 Issue Url: https://pharo.fogbugz.com/f/cases/21363 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 18, 2018

Re: [Pharo-dev] NeoCSV nil-Handling

by Sven Van Caekenberghe

Sean, > On 13 Feb 2018, at 14:39, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I'd like a hook to specify default values more dynamically. The use case is > that I created a glue layer between Magritte and NeoCSV so one can > meta-describe how to extract CSV fields into objects. > > For example: > ``` > descriptionDate > <magritteDescription> > > ^ MADateDescription new > accessor: #date; > priority: 400; > propertyAt: #csvFieldName put: 'Date'; > propertyAt: #csvReader put: [ :s | (s, '/2017') asDate ]; > default: Date today; > yourself > ``` > > The problem is that there doesn't seem to be a way to plug #default: above > into NeoCSV because other hooks like #addField:converter: seem to be skipped > for nil values, shortcutting to a statically described per-csv-file > emptyFieldValue. The initial idea of the empty value (defaulting to nil) and the short circuiting of further conversion, is precisely to help in the writing of the converter blocks, so that [ :s | s asDate ] will never receive nil or an empty string and consequently does not have to test on it. I suppose I could imagine an option like #passEmptyFieldsToConverters, which would allow (and force you) to write converter blocks like [ :s | s isEmptyOrNil ifTrue: [ Date doomsDay ] ifFalse: [ s asDate ] ] so that you can specify your own custom empty value per field. What do you think ? Sven

Feb. 18, 2018

Re: [Pharo-dev] Problem to save packages

by Stephane Ducasse

Hi vincent Welcome to Pharo. - Did you check that you can write in your cache folder? - Is there any files in your cache? - Normally just selecting a package and pressing save should save it. - The exception you report is super strange. Stef On Sun, Feb 18, 2018 at 4:39 PM, Roca Vincent <vincentroca9(a)gmail.com> wrote: > Hi, > I'm a new Pharo user (Pharo 5.0). I have created a package and now I just > want to save it in the package-cache folder. But, when I try to do this > using the Monticello Browser, I get an exception telling me the file I'm > trying to save does not exist. I already managed to save some packages but I > can't anymore. Thanks in advance for your help.

Feb. 18, 2018