Re: [Pharo-dev] Better management of encoding of environment variables

[David T. Lewis via Pharo-dev]

--- Begin Message ---
On Thu, Jan 17, 2019 at 04:57:18PM +0100, Sven Van Caekenberghe wrote:
> 
> > On 16 Jan 2019, at 23:23, Eliot Miranda  wrote:
> > 
> > On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe  wrote:
> > 
> > The image side is perfectly capable of dealing with platform differences
> > in a clean/clear way, and at least we can then use the full power of our
> > language and our tools.
> > 
> Agreed.  At the same time I think it is very important that we don't reply
> on the FFI for environment variable access.  This is a basic cross-platform
> facility.  So I would like to see the environment accessed through primitives,
> but have the image place interpretation on the result of the primitive(s),
> and have the primitive(s) answer a raw result, just a sequence of 
> uninterpreted
>  bytes.
> 
> OK, I can understand that ENV VAR access is more fundamental than FFI
> (although FFI is already essential for Pharo, also during startup).
> 
> > VisualWorks takes this approach and provides a class UninterpretedBytes
> > that the VM is aware of.  That's always seemed like an ugly name and
> > overkill to me.  I would just use ByteArray and provide image level
> > conversion from ByteArray to String, which is what I believe we have anyway.
> 
> Right, bytes are always uninterpreted, else they would be something else.
> We got ByteArray>>#decodedWith: and ByteArray>>#utf8Decoded and our ByteArray
>  inspector decodes automatically if it can.
>

Hi Sven,

I am the author of the getenv primitives, and I am also sadly uninformed
about matters of character sets and strings in a multilingual environment.

The primitives answer environment variable variable values as ByteString
rather than ByteArray. This made sense to me at the time that I wrote it,
because ByteString is easy to display in an inspector, and because it is
easily converted to ByteArray.

For an American English speaker this seems like a good choice, but I
wonder now if it is a bad decision. After all, it is also trivially easy
to convert a ByteArray to ByteString for display in the image.

Would it be helpful to have getenv primitives that answer ByteArray
instead, and to let all conversion (including in OSProcess) be done in
the image?

Thanks,
Dave
 

--- End Message ---

Re: [Pharo-dev] Some clarifications (was DebugSession>>activePC:)

[ducasse via Pharo-dev]

--- Begin Message ---
So when I read your emails everything looks perfect from your side. 
So let it be.

Stef


> On 16 Jan 2019, at 23:15, Eliot Miranda  wrote:
> 
> Hi Stef,
> 
> 
> thanks for taking the time to respond so thoughtfully.
> 
> On Mon, Jan 14, 2019 at 12:20 AM ducasse  > wrote:
> 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.
> 
> You do not have to defend your credentials.  The community is aware of your 
> contributions.
>  
> 
> 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. 
> 
> I do not say "Stephane is emotional so we cannot communicate with him.".  I 
> do think you let your emotions show too much and that it makes communication 
> with you difficult.  But more importantly, a leader is more effective if they 
> can reign in their emotions and not criticize people in public, and so on.  I 
> mention your emotionality not to denigrate you but to hope that communication 
> in the community can improve.  You have as much to gain as anyone, arguably 
> more, from not taking things so personally and being less emotional.  If we 
> analyze the above statement we see that it is coercive: stop criticizing my 
> emotionality or I will stop reading your emails.  One could instead be open: 
> "Why is it that you criticize me as being emotional?", "Can you give me 
> evidence of me being emotional?" etc.  Instead you open with a defensive 
> position, and with a threat.  If, later on, having started filtering out my 
> emails, you found you had to respond again, because we have common interests 
> and those interests cause us to need to interact, you will put yourself in a 
> weak position having to back track on your filtering.
> 
> 
> - 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. 
> 
> No.  I said that my opinion is that time boxing releases is a bad idea. This 
> is not about settings, it is about the content of releases. For me, a release 
> is done when it satisfactorily meets objective release criteria: tests pass, 
> a subset of new features planned for the release are functional, etc.  That 
> releasing something that is incomplete or broken does not help.  I base this 
> on long experience with VisualWorks, Qwaq and Squeak.  
> 
> 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?
> 
> May I make the remark that what others choose to do does not make it right?
>  
> - 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. 
> 
> Yes, and I disagree about the way that they use it, and for good reason.  I 
> have defended my use of Makefiles for a long time, for objective reasons.  I 
> have also proposed good ways for using CMake (to derive a platform-specific 
> header file defining available platform-specific features).  But my objection 
> to Igor's process was that he generated sources on each build.  And my 
> objections to Ronie's use of CMake for the minheadless build are that a) it 
> is slow and b) explicit feature sets are much better than the implicit 
> feature sets that arise when using CMake.
>  
> - 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). 
> 
> Esteban is free to move the code into VMMaker.oscog.  VMMaker.oscog below to 
> 

Re: [Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7.

[Esteban Lorenzano]

Hi,

> On 17 Jan 2019, at 20:19, Torsten Bergmann via Pharo-dev 
>  wrote:
> 
> 
> From: "Torsten Bergmann" 
> Subject: Aw: [Pharo-dev] [ANN] Preparing for release. No more PRs will be 
> accepted on P7.
> Date: 17 January 2019 at 20:19:28 CET
> To: pharo-dev@lists.pharo.org
> Cc: "Pharo Development List" 
> 
> 
> Hi Esteban,
> 
> Good news that we get closer to a release. :)
> 
> What is still the most annoying problem is that inbetween the build number 
> had a hard reset during the switch to an "RC1" candidate
> or after - so build numbers are currently at around "129" as you can see on 
> the mails to the list.

Yes, but we do not have a solution for this. 
Each branch has a different build number and is not possible to tweak it.

> 
> The last shown by Pharo Launcher is 1436 builds with a Pharo 701436.
> 
> This is not only confusing - but still breaks the launcher download. Or did I 
> miss something?

The download is broken not for that. 
Christophe is working in a new version of PL with that problem fixed. 

Cheers!
Esteban

> 
> Thanks
> Torsten
> 
>> Gesendet: Donnerstag, 17. Januar 2019 um 16:18 Uhr
>> Von: "Esteban Lorenzano" 
>> An: "Pharo Development List" 
>> Betreff: [Pharo-dev] [ANN] Preparing for release. No more PRs will be 
>> accepted on P7.
>> 
>> Unless is a show stopper, of course!
>> 
>> Please redirect your PRs to the branch Pharo8.0.
>> 
>> Esteban
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7.

[Torsten Bergmann via Pharo-dev]

--- Begin Message ---
Hi Esteban,

Good news that we get closer to a release. :)

What is still the most annoying problem is that inbetween the build number had 
a hard reset during the switch to an "RC1" candidate
or after - so build numbers are currently at around "129" as you can see on the 
mails to the list.

The last shown by Pharo Launcher is 1436 builds with a Pharo 701436.

This is not only confusing - but still breaks the launcher download. Or did I 
miss something?

Thanks
Torsten

> Gesendet: Donnerstag, 17. Januar 2019 um 16:18 Uhr
> Von: "Esteban Lorenzano" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] [ANN] Preparing for release. No more PRs will be 
> accepted on P7.
>
> Unless is a show stopper, of course!
> 
> Please redirect your PRs to the branch Pharo8.0.
> 
> Esteban
> 
> 

--- End Message ---

Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[Eliot Miranda]

On Thu, Jan 17, 2019 at 8:02 AM Sven Van Caekenberghe  wrote:

>
> > On 17 Jan 2019, at 02:00, Martin McClure  wrote:
> >
> > On 1/16/19 1:24 AM, Nicolas Cellier wrote:
> >> IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion
> because the purpose of a VM is to provide an OS independant façade.
> >
> > I have not looked at this particular problem in detail, so I have no
> opinion on whether the VM is the right place for this particular
> functionality.
> >
> > However, I feel that in general trying to put everything that might be
> OS-specific into the VM is not the best design. To me, the purpose of a
> Smalltalk VM is to present an object-oriented abstraction of the underlying
> machine.
> >
> > Thinking that way leads me to believe that the following are examples of
> things that are good for a VM to do:
> >
> > * Memory is garbage-collected objects, not bytes.
> >
> > * Instructions are bytecodes, not underlying machine instructions.
> >
> > This works well to hide the differences between machine instruction
> sets, memory access, and other low-level things. However, no Smalltalk
> implementation that I know of has been able to use the VM to iron out all
> differences between different OSes.
> >
> > I do believe that it is a good idea to have cleanly-designed layers of
> the system, and that there should be an OS-independent layer and an
> OS-dependent layer with clean separation. But I think it might be better to
> put most of the OS-dependent layer in the image rather than in the VM. For
> one thing, the image is easier to change if there is a bug, or a lacking
> feature, or you're trying to support a new OS.
> >
> > And if it's in the image you get to do the programming in Smalltalk
> rather than C or Slang, which is more fun for most of us. And, let's face
> it, fun is an important metric in an open-source project -- things that are
> fun are much more likely to get done.
>
> +100
>

The VM *is* developed in Smalltalk
https://www.researchgate.net/publication/328509577_Two_Decades_of_Smalltalk_VM_Development_Live_VM_Development_through_Simulation_Tools


> > Regards,
> >
> > -Martin
> >
> >
>
>
>

-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[Sven Van Caekenberghe]

> On 17 Jan 2019, at 02:00, Martin McClure  wrote:
> 
> On 1/16/19 1:24 AM, Nicolas Cellier wrote:
>> IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because 
>> the purpose of a VM is to provide an OS independant façade.
> 
> I have not looked at this particular problem in detail, so I have no opinion 
> on whether the VM is the right place for this particular functionality.
> 
> However, I feel that in general trying to put everything that might be 
> OS-specific into the VM is not the best design. To me, the purpose of a 
> Smalltalk VM is to present an object-oriented abstraction of the underlying 
> machine.
> 
> Thinking that way leads me to believe that the following are examples of 
> things that are good for a VM to do:
> 
> * Memory is garbage-collected objects, not bytes.
> 
> * Instructions are bytecodes, not underlying machine instructions.
> 
> This works well to hide the differences between machine instruction sets, 
> memory access, and other low-level things. However, no Smalltalk 
> implementation that I know of has been able to use the VM to iron out all 
> differences between different OSes.
> 
> I do believe that it is a good idea to have cleanly-designed layers of the 
> system, and that there should be an OS-independent layer and an OS-dependent 
> layer with clean separation. But I think it might be better to put most of 
> the OS-dependent layer in the image rather than in the VM. For one thing, the 
> image is easier to change if there is a bug, or a lacking feature, or you're 
> trying to support a new OS.
> 
> And if it's in the image you get to do the programming in Smalltalk rather 
> than C or Slang, which is more fun for most of us. And, let's face it, fun is 
> an important metric in an open-source project -- things that are fun are much 
> more likely to get done.

+100

> Regards,
> 
> -Martin
> 
> 

[Pharo-dev] [Pharo 8.0] Build #13: 2259-INVALID-ISSUE

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #13 was: SUCCESS.

The Pull Request #2262 was integrated: "2259-INVALID-ISSUE"
Pull request url: https://github.com/pharo-project/pharo/pull/2262

Issue Url: https://pharo.fogbugz.com/f/cases/2259
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/13/

[Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7.

[Esteban Lorenzano]

Unless is a show stopper, of course!

Please redirect your PRs to the branch Pharo8.0.

Esteban

[Pharo-dev] [Pharo 8.0] Build #12: 2193-SystemNavigation-should-use-Smalltalk-globals-but-environment-since-it-has-such-instance-variable

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #12 was: FAILURE.

The Pull Request #2265 was integrated: 
"2193-SystemNavigation-should-use-Smalltalk-globals-but-environment-since-it-has-such-instance-variable"
Pull request url: https://github.com/pharo-project/pharo/pull/2265

Issue Url: https://pharo.fogbugz.com/f/cases/2193
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/12/

[Pharo-dev] [Pharo 7.0] Build #129: Fixes Issue #2256 Recover parameter names, remove unneeded temps in Character

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #129 was: SUCCESS.

The Pull Request #2257 was integrated: "Fixes Issue #2256 Recover parameter 
names, remove unneeded temps in Character"
Pull request url: https://github.com/pharo-project/pharo/pull/2257

Issue Url: https://pharo.fogbugz.com/f/cases/patch
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/129/

[Pharo-dev] [Pharo 7.0] Build #128: 2254 leftover halts

[ci-pharo-ci-jenkins2--- via Pharo-dev]

--- Begin Message ---
There is a new Pharo build available!
  
The status of the build #128 was: FAILURE.

The Pull Request #2255 was integrated: "2254 leftover halts"
Pull request url: https://github.com/pharo-project/pharo/pull/2255

Issue Url: https://pharo.fogbugz.com/f/cases/2254
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/128/
--- End Message ---

Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[Nicolas Cellier]

To be clear, I do not militate for putting everything in the VM. I prefer a
lean VM.
I'm cleaning what already exist in the VM.
If something is in the VM, then it should behave as we expect from a VM:
uniformely.
A small fix in existing code base is more efficient than a full rewrite.
But if a full rewrite is wanted for other reasons, no problem.

Le jeu. 17 janv. 2019 à 02:00, Martin McClure  a
écrit :

> On 1/16/19 1:24 AM, Nicolas Cellier wrote:
> > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion
> > because the purpose of a VM is to provide an OS independant façade.
>
> I have not looked at this particular problem in detail, so I have no
> opinion on whether the VM is the right place for this particular
> functionality.
>
> It is not in the VM currently, only in OSProcessPlugin (and Windows
variant).
If some other plugins would depend on environment variables, then it might
be interesting to provide this feature as a VM service.
I don't know if it is the case.
Also, some platform could have other strategies like querying the Registry
in windows, a configuration file, etc...
So we might provide a service for the basic or multi-level policy.

However, I feel that in general trying to put everything that might be
> OS-specific into the VM is not the best design. To me, the purpose of a
> Smalltalk VM is to present an object-oriented abstraction of the
> underlying machine.
>

Thinking that way leads me to believe that the following are examples of
> things that are good for a VM to do:
>
> * Memory is garbage-collected objects, not bytes.
>
> * Instructions are bytecodes, not underlying machine instructions.
>
> This works well to hide the differences between machine instruction
> sets, memory access, and other low-level things. However, no Smalltalk
> implementation that I know of has been able to use the VM to iron out
> all differences between different OSes.
>
> Files? Sockets?
Until the threaded FFI is consolidated, there is a category of async
algorithms that we cannot easily program at image side.

I do believe that it is a good idea to have cleanly-designed layers of
> the system, and that there should be an OS-independent layer and an
> OS-dependent layer with clean separation. But I think it might be better
> to put most of the OS-dependent layer in the image rather than in the
> VM. For one thing, the image is easier to change if there is a bug, or a
> lacking feature, or you're trying to support a new OS.
>
> For supporting a new OS, I'm not sure.
Having an "edit on known platform-save-resume on new platform-crash" cycles
is not a pleasure.
Well for certain persons, the pleasure can be proportional to the hurdle
height ;)

You must have the bare minimum services (GUI) running before pleasure comes
back.
A Smalltalk without an IDE is not superior to C with a good IDE.
Trial and error is not superior to a good debugger.

And if it's in the image you get to do the programming in Smalltalk
> rather than C or Slang, which is more fun for most of us. And, let's
> face it, fun is an important metric in an open-source project -- things
> that are fun are much more likely to get done.
>
> Regards,
>
> -Martin
>
> For example, the first time I wrote something like Smallapack, there was
no choice: it was thru user defined primitives (st80 or Objectworks).
So I had to write a wrapper in C code for each function exposed, with all
the marshalling of arguments in C!
When came DLLCC it became more fun.

But this does not apply to every library.
If the library depends on tons of preprocessors definitions, macros, then
we currently lack tools for performing an efficient job at image side.
Some possible tools have been sketched in those mailing list, but so far,
they are virtual.

Re: [Pharo-dev] CMake

[Esteban Lorenzano]

Hi,

Yes, when we had the CMake files, I used to generate an Xcode project to work 
on macOS. 
This was very good for work/debug. 

> On 17 Jan 2019, at 03:21, Ben Coman via Pharo-dev  
> wrote:
> 
> 
> From: Ben Coman 
> Subject: CMake
> Date: 17 January 2019 at 03:21:18 CET
> To: Pharo Development List , Squeak Virtual 
> Machine Development Discussion 
> 
> 
> On Thu, 17 Jan 2019 at 06:17, Eliot Miranda  > wrote:
> - 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. 
> 
> Yes, and I disagree about the way that they use it, and for good reason.  I 
> have defended my use of Makefiles for a long time, for objective reasons. 
> 
> These reasons may be technically correct, but in terms of *community* 
> consider it similar to premature optimization.
> For yourself, the priority is a faster build.  Others may prioritize a faster 
> coding workflow using an IDE like Visual Studio.
> Indeed, back when I trialed building minheadless on Windows a *primary* 
> consideration was that it looked easy to 
> use Visual Studio because minheadless had a CMake build.  That led to me 
> contributing a couple of small fixes for win64,
> but without the enticement of CMake I might never have opened that box.   
> 
> Consider then the possibility that a portion of our Windows using community 
> remains untapped 
> because their skill set is Visual Studio and they don't see an easy path to 
> using it with plain makefiles**.
> So it depends on what is better for the *community* to optimize for:
> * faster build-time for incumbents (important because thats where the 
> majority of contributions come from)   
> * broader community involvement with a workflow accelerating IDE (important 
> because growing the vm community is important, from which additional core 
> devs may arise) 
> 
> ** I do understand that plain makefiles can be used with VS, but I'm not 
> clear on the setup and 
> unsure if all the fancy intellisense tools work.
> 
> I have also proposed good ways for using CMake (to derive a platform-specific 
> header file defining available platform-specific features). 
> 
> I presume its the additional multi-build-system features that people want 
> CMake for, not just the using it in name only.
> I can't remember the trade-off between Automake-configure and 
> CMake-configure.  Make using CMake-configure
> would make it easier to co-ordinate parallel CMake and GnuMake systems.  I 
> think I've noticed several large
> code-bases providing both (but I'd have to check)
>  
> 
> But my objection to Igor's process was that he generated sources on each 
> build. 
> 
>  
> And my objections to Ronie's use of CMake for the minheadless build are that 
> a) it is slow and
> 
> I'd like to quantify that.  
> @esteban, I remember you converted minheadless from CMake to Gnumake, but I'm 
> not sure if I've got that right.
> Can both be run off the current HEAD for minheadless?  Or I could compare 
> HEAD with a previous commit that had CMake. 

I do not understand you question :)
What is now in head should be the result of my(our, with Ronie) work.

Esteban  

> 
> 
> b) explicit feature sets are much better than the implicit feature sets that 
> arise when using CMake.
> 
> I'd like to understand this better. Could you expand?
> 
> cheers -ben
> 
> 

[Pharo-dev] [Pharo 7.0] Build #127: 22897-Restore-getEnv-with-a-deprecation

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #127 was: FAILURE.

The Pull Request #2252 was integrated: "22897-Restore-getEnv-with-a-deprecation"
Pull request url: https://github.com/pharo-project/pharo/pull/2252

Issue Url: https://pharo.fogbugz.com/f/cases/22897
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/127/