Re: [Pharo-dev] renaming Matrix to 2dArray

[Clément Bera]

Hi,

long time ago I renamed 2DArray as Matrix. Now our Matrix class does
> not support any of the Matrix operations


Some Matrix operations are implemented:

- I see in Matrix class #+*, #preMultiplyByArray:, #preMultiplyByMatrix:
which are Matrix specific arithmetic (Multiplication of Matrix by Vector
and Matrix) in *Collections-arithmetic protocol. Does that mean these API
will be removed while renaming ? They don't seem to be used anyway.

- There is also #transposed, which is the transposed matrix operator
implemented only for square matrix or an assertion failure is raised. This
method is used, it makes sense to have the transposed operator in Matrix
class but I don't think it would mean anything on a Array2D class (What
does it mean to transpose a 2D Array ?). Is this API going to be removed
and all users patched ? Or maybe we rename it to #squareMatrixTransposed in
Array2D expressing the intent (interpret the Array2D as a Matrix, works
only on square Matrix). What do you think ?

I think it makes sense to rename from Matrix to Array2D only if we patch
first these matrix specific APIs. There are not many we can do it.

Regards,

On Sat, Mar 10, 2018 at 5:35 AM, Esteban A. Maringolo 
wrote:

> I thought you couldn't name classes starting with numbers.
>
> If that wasn't the case I think Array2D would be a better option.
>
> Regards,
>
>
> Esteban A. Maringolo
> Esteban A. Maringolo
>
>
> 2018-03-09 17:46 GMT-03:00 Stephane Ducasse :
> > Hi
> >
> > long time ago I renamed 2DArray as Matrix. Now our Matrix class does
> > not support any of the Matrix operations, so I was thinking that to
> > avoid confusion (people should use polymath) we should rename it back
> > to 2DArray.
> > What do you think?
> >
> > Stef
> >
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.github.io/
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Discord server vanished!

[Clément Bera]

Yeah it's been down for already 11 hours or something like that.

On Sat, Mar 10, 2018 at 3:12 AM, Sean P. DeNigris 
wrote:

> Vincent.Blondeau wrote
> > https://discordapp.com/invite/Sj2rhxn
>
> I confirm this doesn't work. Clicking Accept leads to an error.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.github.io/
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] renaming Matrix to 2dArray

[Esteban A. Maringolo]

I thought you couldn't name classes starting with numbers.

If that wasn't the case I think Array2D would be a better option.

Regards,


Esteban A. Maringolo
Esteban A. Maringolo


2018-03-09 17:46 GMT-03:00 Stephane Ducasse :
> Hi
>
> long time ago I renamed 2DArray as Matrix. Now our Matrix class does
> not support any of the Matrix operations, so I was thinking that to
> avoid confusion (people should use polymath) we should rename it back
> to 2DArray.
> What do you think?
>
> Stef
>

Re: [Pharo-dev] Discord server vanished!

[Sean P. DeNigris]

Vincent.Blondeau wrote
> https://discordapp.com/invite/Sj2rhxn

I confirm this doesn't work. Clicking Accept leads to an error.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Discord server vanished!

[Vincent.Blondeau]

Hi,

It seems that the Pharo discord server is not available anymore at this address 
provided on Pharo.org: https://discordapp.com/invite/Sj2rhxn
And it vanished from the discord app...

Where did it go?

Thanks,
Vincent
<>

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Torsten Bergmann]

Additional portable versions would be nice too (based on a simple ZIP) instead 
of only the installable apps

Re: [Pharo-dev] renaming Matrix to 2dArray

[Tudor Girba]

+1

Doru


> On Mar 9, 2018, at 9:46 PM, Stephane Ducasse  wrote:
> 
> Hi
> 
> long time ago I renamed 2DArray as Matrix. Now our Matrix class does
> not support any of the Matrix operations, so I was thinking that to
> avoid confusion (people should use polymath) we should rename it back
> to 2DArray.
> What do you think?
> 
> Stef
> 

--
www.tudorgirba.com
www.feenk.com

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."

[Pharo-dev] renaming Matrix to 2dArray

[Stephane Ducasse]

Hi

long time ago I renamed 2DArray as Matrix. Now our Matrix class does
not support any of the Matrix operations, so I was thinking that to
avoid confusion (people should use polymath) we should rename it back
to 2DArray.
What do you think?

Stef

Re: [Pharo-dev] [ANN] Cruiser: A Pharo app packager

[Vincent.Blondeau]

Hi Phil!

Indeed! The UFFI is working without the sources. It is integrated in Cruiser as 
a parameter for deployment. You can activate or deactivate it at will:
[cid:image001.png@01D3B78A.D549CDB0]
Let us know if you encounter some issues with it!

Thanks!
Vincent

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Denis 
Kudriashov
Sent: Friday, March 9, 2018 8:14
To: Pharo Development List 
Subject: Re: [Pharo-dev] [ANN] Cruiser: A Pharo app packager

It was solved in this pull request  21124 ffi should work without the sources   



2018-03-09 17:11 GMT+01:00 Eliot Miranda 
>:
Hi Philippe,

On Mar 9, 2018, at 4:50 AM, 
philippe.b...@highoctane.be 
> wrote:
Vincent,

When it comes to UnifiedFFI what would be your advice to have it working?

You will find that it will just work.  Vincent and I discussed how to eliminate 
the UFFI's dependency on the source files as he was developing Cruiser.  I 
think the solution is already released.



I am using quite a few such calls.

Thx for this cool tool, I'll try it out this week end for sure!

Phil

On Thu, Mar 8, 2018, 20:30 
> 
wrote:
Hi Pharoers!

I pleased to announce you the first release of Cruiser: a tool to package your 
Pharo applications. The idea is to quickly convert an application from a 
development environment to a production one. A production environment means:

  *   No writing on the disk
  *   No access to the source code (by the shortcuts, debugger,...)
  *   No error displaying on the interface
  *   The only thing accessible is the user application

I let you discover it on: 
https://github.com/VincentBlondeau/Cruiser

[cid:image002.png@01D3B6D0.B0BAA0B0]

Do not hesitate to ask me questions or contribute to improve it!

Cheers,

Vincent Blondeau
Software Engineer, Software and Controls | Global Product Group
Desk +1 510.572.7499

Lam Research Corporation
4650 Cushing Pkwy, Fremont, CA 94538 
USA
 | www.lamresearch.com
Connect with Lam Research: 
Facebook>
 | 
Twitter>
 | 
LinkedIn>



NOTICE: This e-mail transmission may contain confidential information. If you 
are not the intended recipient, or a person responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution or use of any of the information contained in or attached to this 
message is STRICTLY PROHIBITED. If you have received this transmission in 
error, please immediately notify the sender and destroy the original 
transmission and its attachments without reading them or saving them to disk. 
Thank you.

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Sean P. DeNigris]

Marcus Denker-4 wrote
> comments welcome… 

IHMO the structure is a little confusing because the first heading "Usage"
(Launcher implied) is on the same level as other methods like "Linux
Packages". I think there needs to be something like a header one level
higher like "Other Options" between these two sections.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [ANN] Cruiser: A Pharo app packager

[Denis Kudriashov]

It was solved in this pull request  21124 ffi should work without the
sources

2018-03-09 17:11 GMT+01:00 Eliot Miranda :

> Hi Philippe,
>
> On Mar 9, 2018, at 4:50 AM, philippe.b...@highoctane.be <
> philippe.b...@gmail.com> wrote:
>
> Vincent,
>
> When it comes to UnifiedFFI what would be your advice to have it working?
>
>
> You will find that it will just work.  Vincent and I discussed how to
> eliminate the UFFI's dependency on the source files as he was developing
> Cruiser.  I think the solution is already released.
>
>
> I am using quite a few such calls.
>
> Thx for this cool tool, I'll try it out this week end for sure!
>
> Phil
>
> On Thu, Mar 8, 2018, 20:30  wrote:
>
>> Hi Pharoers!
>>
>> I pleased to announce you the first release of Cruiser: a tool to package
>> your Pharo applications. The idea is to quickly convert an application from
>> a development environment to a production one. A production environment
>> means:
>>
>>   *   No writing on the disk
>>   *   No access to the source code (by the shortcuts, debugger,...)
>>   *   No error displaying on the interface
>>   *   The only thing accessible is the user application
>>
>> I let you discover it on: https://github.com/VincentBlondeau/Cruiser
>>
>> [cid:image002.png@01D3B6D0.B0BAA0B0]
>>
>> Do not hesitate to ask me questions or contribute to improve it!
>>
>> Cheers,
>>
>> Vincent Blondeau
>> Software Engineer, Software and Controls | Global Product Group
>> Desk +1 510.572.7499
>>
>> Lam Research Corporation
>> 4650 Cushing Pkwy, Fremont, CA 94538 USA
>> 
>> | www.lamresearch.com
>> Connect with Lam Research: Facebook> com/LamResearchCorporation> | Twitter |
>> LinkedIn
>>
>> 
>>
>> NOTICE: This e-mail transmission may contain confidential information. If
>> you are not the intended recipient, or a person responsible for delivering
>> it to the intended recipient, you are hereby notified that any disclosure,
>> copying, distribution or use of any of the information contained in or
>> attached to this message is STRICTLY PROHIBITED. If you have received this
>> transmission in error, please immediately notify the sender and destroy the
>> original transmission and its attachments without reading them or saving
>> them to disk. Thank you.
>>
>

Re: [Pharo-dev] [ANN] Cruiser: A Pharo app packager

[Eliot Miranda]

Hi Philippe,

> On Mar 9, 2018, at 4:50 AM, philippe.b...@highoctane.be 
>  wrote:
> 
> Vincent,
> 
> When it comes to UnifiedFFI what would be your advice to have it working?

You will find that it will just work.  Vincent and I discussed how to eliminate 
the UFFI's dependency on the source files as he was developing Cruiser.  I 
think the solution is already released.

> 
> I am using quite a few such calls.
> 
> Thx for this cool tool, I'll try it out this week end for sure!
> 
> Phil
> 
>> On Thu, Mar 8, 2018, 20:30  wrote:
>> Hi Pharoers!
>> 
>> I pleased to announce you the first release of Cruiser: a tool to package 
>> your Pharo applications. The idea is to quickly convert an application from 
>> a development environment to a production one. A production environment 
>> means:
>> 
>>   *   No writing on the disk
>>   *   No access to the source code (by the shortcuts, debugger,...)
>>   *   No error displaying on the interface
>>   *   The only thing accessible is the user application
>> 
>> I let you discover it on: https://github.com/VincentBlondeau/Cruiser
>> 
>> [cid:image002.png@01D3B6D0.B0BAA0B0]
>> 
>> Do not hesitate to ask me questions or contribute to improve it!
>> 
>> Cheers,
>> 
>> Vincent Blondeau
>> Software Engineer, Software and Controls | Global Product Group
>> Desk +1 510.572.7499
>> 
>> Lam Research Corporation
>> 4650 Cushing Pkwy, Fremont, CA 94538 USA | www.lamresearch.com
>> Connect with Lam Research: 
>> Facebook | 
>> Twitter | 
>> LinkedIn
>> 
>> 
>> 
>> NOTICE: This e-mail transmission may contain confidential information. If 
>> you are not the intended recipient, or a person responsible for delivering 
>> it to the intended recipient, you are hereby notified that any disclosure, 
>> copying, distribution or use of any of the information contained in or 
>> attached to this message is STRICTLY PROHIBITED. If you have received this 
>> transmission in error, please immediately notify the sender and destroy the 
>> original transmission and its attachments without reading them or saving 
>> them to disk. Thank you.

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

[Alistair Grant]

On 9 March 2018 at 16:56, Pavel Krivanek  wrote:
> 2018-03-09 16:47 GMT+01:00 Alistair Grant :
>> Hi Pavel,
>>
>> On 9 March 2018 at 16:12, Pavel Krivanek  wrote:
>>> 2018-03-09 16:02 GMT+01:00 Alistair Grant :
 Hi Pavel,

 I tried to get this working on Ubuntu 16.04 and found the following:

 - The compilation failed unless I added the '-fPIC' flag (as suggested by 
 gcc).
>>>
>>> is it on 64-bit system and VM?
>>
>> Yep.
>
> I will check that, I guess some package is missing in this Ubuntu
> environment because I think I checked it on the same system without
> this issue.
>
>>
>>
 - The example code in the TerminalEmulator class comment references
 ProcessEndpoint, but the class doesn't exist.
>>>
>>> Thanks, this class was renamed
>>
>> To PseudoTTYEndpoint, it looks like.
>>
>> Cool!  The interactive terminal is up and running.
>>
>> Is it possible to have a cursor?
>
> the original implementation had it, I need to only fix it ;-)
>>
>> How does one pass more than one argument, for example, if I want to
>> execute "ls -l -h", what should be the format be (ignore that the two
>> arguments can be combined in this case, it's just as a simple
>> example)?
>>
>> PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l -h')
>>
>> produces:
>>
>> ls: invalid option -- ' '
>> Try 'ls --help' for more information.
>>
>>
>> PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l' '-h')
>>
>> ignores the second argument.
>
> In this prototype implementation, only one argument is allowed because
> to pass variable arguments list with FFI is not trivial. It will be
> fixed soon.

Great, thanks!

Cheers,
Alistair

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

[Pavel Krivanek]

2018-03-09 16:47 GMT+01:00 Alistair Grant :
> Hi Pavel,
>
> On 9 March 2018 at 16:12, Pavel Krivanek  wrote:
>> 2018-03-09 16:02 GMT+01:00 Alistair Grant :
>>> Hi Pavel,
>>>
>>> I tried to get this working on Ubuntu 16.04 and found the following:
>>>
>>> - The compilation failed unless I added the '-fPIC' flag (as suggested by 
>>> gcc).
>>
>> is it on 64-bit system and VM?
>
> Yep.

I will check that, I guess some package is missing in this Ubuntu
environment because I think I checked it on the same system without
this issue.

>
>
>>> - The example code in the TerminalEmulator class comment references
>>> ProcessEndpoint, but the class doesn't exist.
>>
>> Thanks, this class was renamed
>
> To PseudoTTYEndpoint, it looks like.
>
> Cool!  The interactive terminal is up and running.
>
> Is it possible to have a cursor?

the original implementation had it, I need to only fix it ;-)
>
> How does one pass more than one argument, for example, if I want to
> execute "ls -l -h", what should be the format be (ignore that the two
> arguments can be combined in this case, it's just as a simple
> example)?
>
> PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l -h')
>
> produces:
>
> ls: invalid option -- ' '
> Try 'ls --help' for more information.
>
>
> PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l' '-h')
>
> ignores the second argument.

In this prototype implementation, only one argument is allowed because
to pass variable arguments list with FFI is not trivial. It will be
fixed soon.

>
> Thanks!
> Alistair
>
>
>> Cheers,
>> -- Pavel
>>
>>>
>>> Pharo 7.0
>>> Build information:
>>> Pharo-7.0+alpha.build.674.sha.57447e756fa6fcf1877f9d0d1cda235b3b63c807
>>> (64 Bit)
>>>
>>>
>>> Cheers,
>>> Alistair
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 5 March 2018 at 10:29, Pavel Krivanek  wrote:
 Hi,

 Guille is working on the Iceberg improvements and he wanted to be able to
 open a terminal window on top of the repository and interact with it via 
 the
 command line. So we looked at this issue because I already in December made
 some experiments with the terminal emulation in Pharo.

 In past, the Squeak had a working terminal emulation that used
 PseudoTTYPlugin. The VM is not built with this code for a long time but I
 tried to replace it with a small C library and then wrote an FFI interface
 to it. Together with that, I ported most of the old code Squeak code to
 Pharo.

 With Guille we tried to avoid usage of such external library and wrote an
 FFI interface to all the required LibC functions. We were successful but we
 realized that there are several issues that are limiting us.

 When you want to execute a separate process for the program that you want 
 to
 open in terminal (typically the Bash), you need to redirect the standard IO
 files, create a fork of your process, do some additional initialization in
 it and call 'exec' on it. In the parent process, you change redirected IO
 files back to the original values.

 But the problem is that between the FFI calls from Smalltalk the VM can do 
 a
 lot of things including garbage collection etc. On OS X the fork() function
 has the following limitation described in man:

 "There are limits to what you can do in the child process. To be totally
 safe you should restrict your yourself to only executing async-signal safe
 operations until such time as one of the exec functions is called.  All
 APIs, including global data symbols, in any framework or library should be
 assumed to be unsafe after a fork() unless explicitly documented to be safe
 or async-signal safe.  If you need to use these frameworks in the child
 process, you must exec.  In this
 situation it is reasonable to exec your-self. yourself."


 As the result in most cases (but not all) the fork() and exec() pair from
 the Smalltalk side fails on OS X. Linux does not have this limitation
 however even there we found an issue. It is bound to the fact that fork()
 makes a fork of all the parent process that uses the same resources. As 
 soon
 as Pharo is opened in a window and X11 is involved (the window wants to be
 repainted), it can lead to the VM crash.

 So we learned that unfortunately we currently cannot use image-only FFI 
 code
 for this task. We need a C library or VM plugin.

 The repository of the terminal emulator is here:
 https://github.com/pavel-krivanek/terminal

 and can be loaded using the following code:

 Metacello new
   baseline: 'TerminalEmulator';
   repository: 'github://pavel-krivanek/terminal/src';
   load.

 #TerminalEmulator asClass compileLibrary.


 It compiles and links the small library with only one function using the 
 

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

[Alistair Grant]

Hi Pavel,

On 9 March 2018 at 16:12, Pavel Krivanek  wrote:
> 2018-03-09 16:02 GMT+01:00 Alistair Grant :
>> Hi Pavel,
>>
>> I tried to get this working on Ubuntu 16.04 and found the following:
>>
>> - The compilation failed unless I added the '-fPIC' flag (as suggested by 
>> gcc).
>
> is it on 64-bit system and VM?

Yep.


>> - The example code in the TerminalEmulator class comment references
>> ProcessEndpoint, but the class doesn't exist.
>
> Thanks, this class was renamed

To PseudoTTYEndpoint, it looks like.

Cool!  The interactive terminal is up and running.

Is it possible to have a cursor?

How does one pass more than one argument, for example, if I want to
execute "ls -l -h", what should be the format be (ignore that the two
arguments can be combined in this case, it's just as a simple
example)?

PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l -h')

produces:

ls: invalid option -- ' '
Try 'ls --help' for more information.


PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l' '-h')

ignores the second argument.


Thanks!
Alistair


> Cheers,
> -- Pavel
>
>>
>> Pharo 7.0
>> Build information:
>> Pharo-7.0+alpha.build.674.sha.57447e756fa6fcf1877f9d0d1cda235b3b63c807
>> (64 Bit)
>>
>>
>> Cheers,
>> Alistair
>>
>>
>>
>>
>>
>>
>> On 5 March 2018 at 10:29, Pavel Krivanek  wrote:
>>> Hi,
>>>
>>> Guille is working on the Iceberg improvements and he wanted to be able to
>>> open a terminal window on top of the repository and interact with it via the
>>> command line. So we looked at this issue because I already in December made
>>> some experiments with the terminal emulation in Pharo.
>>>
>>> In past, the Squeak had a working terminal emulation that used
>>> PseudoTTYPlugin. The VM is not built with this code for a long time but I
>>> tried to replace it with a small C library and then wrote an FFI interface
>>> to it. Together with that, I ported most of the old code Squeak code to
>>> Pharo.
>>>
>>> With Guille we tried to avoid usage of such external library and wrote an
>>> FFI interface to all the required LibC functions. We were successful but we
>>> realized that there are several issues that are limiting us.
>>>
>>> When you want to execute a separate process for the program that you want to
>>> open in terminal (typically the Bash), you need to redirect the standard IO
>>> files, create a fork of your process, do some additional initialization in
>>> it and call 'exec' on it. In the parent process, you change redirected IO
>>> files back to the original values.
>>>
>>> But the problem is that between the FFI calls from Smalltalk the VM can do a
>>> lot of things including garbage collection etc. On OS X the fork() function
>>> has the following limitation described in man:
>>>
>>> "There are limits to what you can do in the child process. To be totally
>>> safe you should restrict your yourself to only executing async-signal safe
>>> operations until such time as one of the exec functions is called.  All
>>> APIs, including global data symbols, in any framework or library should be
>>> assumed to be unsafe after a fork() unless explicitly documented to be safe
>>> or async-signal safe.  If you need to use these frameworks in the child
>>> process, you must exec.  In this
>>> situation it is reasonable to exec your-self. yourself."
>>>
>>>
>>> As the result in most cases (but not all) the fork() and exec() pair from
>>> the Smalltalk side fails on OS X. Linux does not have this limitation
>>> however even there we found an issue. It is bound to the fact that fork()
>>> makes a fork of all the parent process that uses the same resources. As soon
>>> as Pharo is opened in a window and X11 is involved (the window wants to be
>>> repainted), it can lead to the VM crash.
>>>
>>> So we learned that unfortunately we currently cannot use image-only FFI code
>>> for this task. We need a C library or VM plugin.
>>>
>>> The repository of the terminal emulator is here:
>>> https://github.com/pavel-krivanek/terminal
>>>
>>> and can be loaded using the following code:
>>>
>>> Metacello new
>>>   baseline: 'TerminalEmulator';
>>>   repository: 'github://pavel-krivanek/terminal/src';
>>>   load.
>>>
>>> #TerminalEmulator asClass compileLibrary.
>>>
>>>
>>> It compiles and links the small library with only one function using the GCC
>>> so the machine needs to have a proper development environment.
>>>
>>> The terminal emulator is in very early stage and has a lot of issues like
>>> processes cleanup, drawing, keyboard input etc. etc. If you are interested
>>> in it, feel free to contribute.
>>>
>>> Cheers,
>>> -- Pavel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

[Pavel Krivanek]

2018-03-09 16:02 GMT+01:00 Alistair Grant :
> Hi Pavel,
>
> I tried to get this working on Ubuntu 16.04 and found the following:
>
> - The compilation failed unless I added the '-fPIC' flag (as suggested by 
> gcc).

is it on 64-bit system and VM?

> - The example code in the TerminalEmulator class comment references
> ProcessEndpoint, but the class doesn't exist.

Thanks, this class was renamed

Cheers,
-- Pavel

>
> Pharo 7.0
> Build information:
> Pharo-7.0+alpha.build.674.sha.57447e756fa6fcf1877f9d0d1cda235b3b63c807
> (64 Bit)
>
>
> Cheers,
> Alistair
>
>
>
>
>
>
> On 5 March 2018 at 10:29, Pavel Krivanek  wrote:
>> Hi,
>>
>> Guille is working on the Iceberg improvements and he wanted to be able to
>> open a terminal window on top of the repository and interact with it via the
>> command line. So we looked at this issue because I already in December made
>> some experiments with the terminal emulation in Pharo.
>>
>> In past, the Squeak had a working terminal emulation that used
>> PseudoTTYPlugin. The VM is not built with this code for a long time but I
>> tried to replace it with a small C library and then wrote an FFI interface
>> to it. Together with that, I ported most of the old code Squeak code to
>> Pharo.
>>
>> With Guille we tried to avoid usage of such external library and wrote an
>> FFI interface to all the required LibC functions. We were successful but we
>> realized that there are several issues that are limiting us.
>>
>> When you want to execute a separate process for the program that you want to
>> open in terminal (typically the Bash), you need to redirect the standard IO
>> files, create a fork of your process, do some additional initialization in
>> it and call 'exec' on it. In the parent process, you change redirected IO
>> files back to the original values.
>>
>> But the problem is that between the FFI calls from Smalltalk the VM can do a
>> lot of things including garbage collection etc. On OS X the fork() function
>> has the following limitation described in man:
>>
>> "There are limits to what you can do in the child process. To be totally
>> safe you should restrict your yourself to only executing async-signal safe
>> operations until such time as one of the exec functions is called.  All
>> APIs, including global data symbols, in any framework or library should be
>> assumed to be unsafe after a fork() unless explicitly documented to be safe
>> or async-signal safe.  If you need to use these frameworks in the child
>> process, you must exec.  In this
>> situation it is reasonable to exec your-self. yourself."
>>
>>
>> As the result in most cases (but not all) the fork() and exec() pair from
>> the Smalltalk side fails on OS X. Linux does not have this limitation
>> however even there we found an issue. It is bound to the fact that fork()
>> makes a fork of all the parent process that uses the same resources. As soon
>> as Pharo is opened in a window and X11 is involved (the window wants to be
>> repainted), it can lead to the VM crash.
>>
>> So we learned that unfortunately we currently cannot use image-only FFI code
>> for this task. We need a C library or VM plugin.
>>
>> The repository of the terminal emulator is here:
>> https://github.com/pavel-krivanek/terminal
>>
>> and can be loaded using the following code:
>>
>> Metacello new
>>   baseline: 'TerminalEmulator';
>>   repository: 'github://pavel-krivanek/terminal/src';
>>   load.
>>
>> #TerminalEmulator asClass compileLibrary.
>>
>>
>> It compiles and links the small library with only one function using the GCC
>> so the machine needs to have a proper development environment.
>>
>> The terminal emulator is in very early stage and has a lot of issues like
>> processes cleanup, drawing, keyboard input etc. etc. If you are interested
>> in it, feel free to contribute.
>>
>> Cheers,
>> -- Pavel
>>
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

[Alistair Grant]

Hi Pavel,

I tried to get this working on Ubuntu 16.04 and found the following:

- The compilation failed unless I added the '-fPIC' flag (as suggested by gcc).
- The example code in the TerminalEmulator class comment references
ProcessEndpoint, but the class doesn't exist.

Pharo 7.0
Build information:
Pharo-7.0+alpha.build.674.sha.57447e756fa6fcf1877f9d0d1cda235b3b63c807
(64 Bit)


Cheers,
Alistair






On 5 March 2018 at 10:29, Pavel Krivanek  wrote:
> Hi,
>
> Guille is working on the Iceberg improvements and he wanted to be able to
> open a terminal window on top of the repository and interact with it via the
> command line. So we looked at this issue because I already in December made
> some experiments with the terminal emulation in Pharo.
>
> In past, the Squeak had a working terminal emulation that used
> PseudoTTYPlugin. The VM is not built with this code for a long time but I
> tried to replace it with a small C library and then wrote an FFI interface
> to it. Together with that, I ported most of the old code Squeak code to
> Pharo.
>
> With Guille we tried to avoid usage of such external library and wrote an
> FFI interface to all the required LibC functions. We were successful but we
> realized that there are several issues that are limiting us.
>
> When you want to execute a separate process for the program that you want to
> open in terminal (typically the Bash), you need to redirect the standard IO
> files, create a fork of your process, do some additional initialization in
> it and call 'exec' on it. In the parent process, you change redirected IO
> files back to the original values.
>
> But the problem is that between the FFI calls from Smalltalk the VM can do a
> lot of things including garbage collection etc. On OS X the fork() function
> has the following limitation described in man:
>
> "There are limits to what you can do in the child process. To be totally
> safe you should restrict your yourself to only executing async-signal safe
> operations until such time as one of the exec functions is called.  All
> APIs, including global data symbols, in any framework or library should be
> assumed to be unsafe after a fork() unless explicitly documented to be safe
> or async-signal safe.  If you need to use these frameworks in the child
> process, you must exec.  In this
> situation it is reasonable to exec your-self. yourself."
>
>
> As the result in most cases (but not all) the fork() and exec() pair from
> the Smalltalk side fails on OS X. Linux does not have this limitation
> however even there we found an issue. It is bound to the fact that fork()
> makes a fork of all the parent process that uses the same resources. As soon
> as Pharo is opened in a window and X11 is involved (the window wants to be
> repainted), it can lead to the VM crash.
>
> So we learned that unfortunately we currently cannot use image-only FFI code
> for this task. We need a C library or VM plugin.
>
> The repository of the terminal emulator is here:
> https://github.com/pavel-krivanek/terminal
>
> and can be loaded using the following code:
>
> Metacello new
>   baseline: 'TerminalEmulator';
>   repository: 'github://pavel-krivanek/terminal/src';
>   load.
>
> #TerminalEmulator asClass compileLibrary.
>
>
> It compiles and links the small library with only one function using the GCC
> so the machine needs to have a proper development environment.
>
> The terminal emulator is in very early stage and has a lot of issues like
> processes cleanup, drawing, keyboard input etc. etc. If you are interested
> in it, feel free to contribute.
>
> Cheers,
> -- Pavel
>
>
>
>
>
>
>

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Marcus Denker]

> On 9 Mar 2018, at 14:01, Marcus Denker  wrote:
> 
> 
> 
>> On 9 Mar 2018, at 13:58, Cyril Ferlicot  wrote:
>> 
>> On Fri, Mar 9, 2018 at 1:53 PM, Marcus Denker  wrote:
>>> Hi,
>>> 
>>> With Christoph we did a version of the download page that points users to
>>> the “Pharo Launcher” instead of the zips that just contained one vm and the
>>> last image.
>>> 
>>> http://pharo.org/download
>>> 
>>> comments welcome…
>>> 
>> Hi!
>> I am totally in favour of referencing Pharo Launcher in the Pharo
>> download page, but I'm not sure it should totally replace the old
>> page.
>> In my opinion, it would be good to have both.
> 
> The problem is that things are getting *very* complex, and every new way to 
> download Pharo makes things even more complex…
> 
> I really do not know how to structure that page if the launcher is added as 
> yet another way.

Of course Linux package I kept (they are in the Linux Package section).

What do you miss? The .zip files that have vm+sources+image? 

I think the launcher replaces the “this is the easiest download” aka the .zip 
files.

For the “single downloads” (point the the last vm, the last image), maybe 
adding that section back is needed… 

Marcus

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Marcus Denker]

> On 9 Mar 2018, at 13:58, Cyril Ferlicot  wrote:
> 
> On Fri, Mar 9, 2018 at 1:53 PM, Marcus Denker  wrote:
>> Hi,
>> 
>> With Christoph we did a version of the download page that points users to
>> the “Pharo Launcher” instead of the zips that just contained one vm and the
>> last image.
>> 
>> http://pharo.org/download
>> 
>> comments welcome…
>> 
> Hi!
> I am totally in favour of referencing Pharo Launcher in the Pharo
> download page, but I'm not sure it should totally replace the old
> page.
> In my opinion, it would be good to have both.

The problem is that things are getting *very* complex, and every new way to 
download Pharo makes things even more complex…

I really do not know how to structure that page if the launcher is added as yet 
another way.

Marcus

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Cyril Ferlicot]

On Fri, Mar 9, 2018 at 1:53 PM, Marcus Denker  wrote:
> Hi,
>
> With Christoph we did a version of the download page that points users to
> the “Pharo Launcher” instead of the zips that just contained one vm and the
> last image.
>
> http://pharo.org/download
>
> comments welcome…
>
Hi!
I am totally in favour of referencing Pharo Launcher in the Pharo
download page, but I'm not sure it should totally replace the old
page.
In my opinion, it would be good to have both.

> Marcus

-- 
Cyril Ferlicot
https://ferlicot.fr

[Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Marcus Denker]

Hi,

With Christoph we did a version of the download page that points users to the 
“Pharo Launcher” instead of the zips that just contained one vm and the last 
image.

http://pharo.org/download 

comments welcome… 

Marcus

Re: [Pharo-dev] [ANN] Cruiser: A Pharo app packager

[philippe.b...@highoctane.be]

Vincent,

When it comes to UnifiedFFI what would be your advice to have it working?

I am using quite a few such calls.

Thx for this cool tool, I'll try it out this week end for sure!

Phil

On Thu, Mar 8, 2018, 20:30  wrote:

> Hi Pharoers!
>
> I pleased to announce you the first release of Cruiser: a tool to package
> your Pharo applications. The idea is to quickly convert an application from
> a development environment to a production one. A production environment
> means:
>
>   *   No writing on the disk
>   *   No access to the source code (by the shortcuts, debugger,...)
>   *   No error displaying on the interface
>   *   The only thing accessible is the user application
>
> I let you discover it on: https://github.com/VincentBlondeau/Cruiser
>
> [cid:image002.png@01D3B6D0.B0BAA0B0]
>
> Do not hesitate to ask me questions or contribute to improve it!
>
> Cheers,
>
> Vincent Blondeau
> Software Engineer, Software and Controls | Global Product Group
> Desk +1 510.572.7499
>
> Lam Research Corporation
> 4650 Cushing Pkwy, Fremont, CA 94538 USA | www.lamresearch.com
> Connect with Lam Research: Facebook<
> https://www.facebook.com/LamResearchCorporation> | Twitter<
> https://twitter.com/lamresearch> | LinkedIn<
> https://www.linkedin.com/company/lam-research>
>
> 
>
> NOTICE: This e-mail transmission may contain confidential information. If
> you are not the intended recipient, or a person responsible for delivering
> it to the intended recipient, you are hereby notified that any disclosure,
> copying, distribution or use of any of the information contained in or
> attached to this message is STRICTLY PROHIBITED. If you have received this
> transmission in error, please immediately notify the sender and destroy the
> original transmission and its attachments without reading them or saving
> them to disk. Thank you.
>

[Pharo-dev] [Pharo 7.0-dev] Build #674: 21521-File-out-and-file-in-code-leads-to-wrong-line-ending-in-the-image2

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #674 was: SUCCESS.

The Pull Request #1049 was integrated: 
"21521-File-out-and-file-in-code-leads-to-wrong-line-ending-in-the-image2"
Pull request url: https://github.com/pharo-project/pharo/pull/1049

Issue Url: https://pharo.fogbugz.com/f/cases/21521
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/674/

[Pharo-dev] [Pharo 7.0-dev] Build #673: 21216-Now-Trait-isBehaviour-returns-true-and-it-affects-ChangeSet-method

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #673 was: SUCCESS.

The Pull Request #1039 was integrated: 
"21216-Now-Trait-isBehaviour-returns-true-and-it-affects-ChangeSet-method"
Pull request url: https://github.com/pharo-project/pharo/pull/1039

Issue Url: https://pharo.fogbugz.com/f/cases/21216
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/673/

[Pharo-dev] [Pharo 7.0-dev] Build #672: 21515-Update-bootstrap-to-bootstrapImage-1.4-and-7.0-VM

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #672 was: SUCCESS.

The Pull Request #1048 was integrated: 
"21515-Update-bootstrap-to-bootstrapImage-1.4-and-7.0-VM"
Pull request url: https://github.com/pharo-project/pharo/pull/1048

Issue Url: https://pharo.fogbugz.com/f/cases/21515
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/672/

[Pharo-dev] [Pharo 7.0-dev] Build #671: 21494-Change-boostrap-to-not-load-Spec-Debugger

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #671 was: SUCCESS.

The Pull Request #1034 was integrated: 
"21494-Change-boostrap-to-not-load-Spec-Debugger"
Pull request url: https://github.com/pharo-project/pharo/pull/1034

Issue Url: https://pharo.fogbugz.com/f/cases/21494
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/671/

[Pharo-dev] [Pharo 7.0-dev] Build #670: 21042-file-out-does-not-work-from-browser

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #670 was: SUCCESS.

The Pull Request #1044 was integrated: 
"21042-file-out-does-not-work-from-browser"
Pull request url: https://github.com/pharo-project/pharo/pull/1044

Issue Url: https://pharo.fogbugz.com/f/cases/21042
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/670/