Re: [Pharo-users] Your picture on Pharo contributors :)

[Trygve Reenskaug]

With all due respect, I am reluctant to sign this agreement. It commits 
me to whatever might be published at the given URL at any time in the 
future.  I wonder why you didn't make the agreement concrete by copying 
the current text into it?


Current contents of :

   "Copyright (c)  

   Permission is hereby granted, free of charge, to any person
   obtaining a copy
 of this software and associated documentation files (the
   "Software"), to deal
 in the Software without restriction, including without limitation
   the rights
 to use, copy, modify, merge, publish, distribute, sublicense,
   and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:

   The above copyright notice and this permission notice shall be
   included in
 all copies or substantial portions of the Software.

   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
   EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
   MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
   SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
   ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   DEALINGS IN
 THE SOFTWARE."

I have no problem with signing this, but I have a problem with signing a 
carte blanche.

--Trygve



On 26.09.2014 07:25, stepharo wrote:

Hi guys

do not forget to sign the license agreement
http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf
and send us your picture to be added to
http://pharo.org/about

Stef







--

Trygve Reenskaug  mailto: tryg...@ifi.uio.no
Morgedalsvn. 5A   http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27

Re: [Pharo-users] invoking python from pharo

[kilon alios]

have you tried Ephestos ?

does it work for you ?

do you like the way it works ?

what you want to do with it ?

I would appreciate some feedback. It does work well for me so far, but of
course I want to read other people's opinion about it.

I want to make it very easy for pharoers to port python libraries to pharo
and mix pharo and python code or why not even support other languages. For
example this morning I was looking at Meteor.js which is working similarly
to Ephestos in the sense it uses a socket to send data from client to
server that then server uses that data to update the webpage, it means that
javascript can code this way in a live coding workflow web apps and web
pages. Of course Meteor.js is far more sophisticated with database support,
template support, authorisation and much more.

On Thu, Sep 25, 2014 at 11:26 PM, Pablo R. Digonzelli  wrote:

> Excellent, I will waiting ...
>
>
> --
> *Ing. Pablo Digonzelli*
> Software Solutions
> IP-Solutiones SRL
> Metrotec SRL
> 25 de Mayo 521
> Email: pdigonze...@softsargentina.com
> pdigonze...@gmail.com
> Cel: 5493815982714
>
> --
> *De: *"kilon alios" 
> *Para: *"Any question about pharo is welcome"  >
> *Enviados: *Jueves, 25 de Septiembre 2014 16:01:08
>
> *Asunto: *Re: [Pharo-users] invoking python from pharo
>
> Its far from excellent. Its not as tested as I want it to be, and the code
> could be much better but it works and makes interfacing with python code
> very easy.
> Its also an ongoing project that I will keep adding feature to , for
> example I would like to extend pharo syntax to more complex stuff than
> calling python methods like defining python classes etc so you wont have to
> use sendMessage and getValue at all and not have to write a line of python
> code. In short do all your python coding using 100% pharo syntax. But that
> will take a lot of time to do because it will require a fully python syntax
> parser.
> I have updated the code to resolve the error when issuing a command to
> close the bridge with
>
> Ephestos sendMessage:'exit'.
>
> This command basically terminate pyAtlas and closes it server socket.
>
> I dont know if its Pharo or Python or Macos but it looks like it takes
> time to free up the socket address so you will need 20 seconds to restart
> pyAtlas again. I tried to set the timeout of the socket to 1 second but it
> looks to me it still uses the default 20 seconds timeout. I guess 20 sec is
> not that bad for a pre alpha software :D
>
> But anyway that should not be a problem since you will have to rerun
> pyatlas every 20 sec , which is something you would not want to do .
>
> I was actually planning to test Ephestos with pyQT and pyCuda and make a
> youtube video about it but have not found the time yet. Probably in the
> weekend.
>
> On Thu, Sep 25, 2014 at 9:23 PM, Pablo R. Digonzelli <
> pdigonze...@gmail.com> wrote:
>
>> Yes , I was aware of the excellent work of kilon.
>> I was hoping that this be the way to solve my issue.
>>
>> Thanks kilon, I will follow your instructions and comment the results
>> into the list.
>>
>>
>> --
>> *Ing. Pablo Digonzelli*
>> Software Solutions
>> IP-Solutiones SRL
>> Metrotec SRL
>> 25 de Mayo 521
>> Email: pdigonze...@softsargentina.com
>> pdigonze...@gmail.com
>> Cel: 5493815982714
>>
>> --
>> *De: *"kilon alios" 
>> *Para: *"Any question about pharo is welcome" <
>> pharo-users@lists.pharo.org>
>> *Enviados: *Jueves, 25 de Septiembre 2014 14:13:34
>> *Asunto: *Re: [Pharo-users] invoking python from pharo
>>
>> a minor correction to the previous email its
>> python3 pyatlas.py and not python3 pyAtlas.py
>>
>> also I forgot to make clear that it works for pyhton 2.7 and python 3.
>>
>> On Thu, Sep 25, 2014 at 8:11 PM, kilon alios 
>> wrote:
>>
>>> Hi there, I promised to do this a long time ago, but since you asked it
>>> I done it now.
>>> So as Ben said I am the author of Ephestos, a communication bridge
>>> between Blender and Pharo .
>>>
>>> To go directly to the how to . Ephestos is basically a socket bridge
>>> that send via sockets strings from pharo to python that then python
>>> executes as python commands.
>>>
>>> Ephestos is made so it works inside blender but I promised Atals a spin
>>> off project that allows the same socket bridge to be used as a standalone.
>>> To use do the following.
>>>
>>> 1) Get Ephestos , you can find it and install it with the configuration
>>> browser in your image in Pharo 3 and Pharo 4. Make sure you have a recent
>>> release though because I added it recently.
>>>
>>> 2) Get pyAtlas , this is the python side , you can get it from here -->
>>> https://github.com/kilon/pyAtlas
>>>
>>> 3)  in your command line cd to the pyAtlas directory and execute :
>>> python3 pyAtlas.py
>>>
>>> 4) in Pharo you can now try any python code you want
>>>
>>> for example
>>>
>>> Ephestos sendMessage: 'print("hello world")'.
>>> Ephesto

[Pharo-users] How to set a white background with Spec ?

[Annick Fron]

Hi,

I am using a window with spec, where can I define a white background 
for it ?

Annick

Re: [Pharo-users] Ridiculous we are

[Henrik Johansen]

On 25 Sep 2014, at 8:55 , Alain Rastoul  wrote:

> Le 25/09/2014 07:23, Sven Van Caekenberghe a écrit :
>> 
>> On 25 Sep 2014, at 01:04, Alain Rastoul  wrote:
>> 
>>> Le 25/09/2014 00:06, Sven Van Caekenberghe a écrit :
 Alain,
>>> 
 The character encoding situation in Pharo is pretty good actually. The 
 only problem is that there is some old school code left that encodes 
 strings into strings, but today you can easily write much better and 
 conceptually correct code.
 
 You could have a look at this draft chapter of the upcoming 'Enterprise 
 Pharo' book that I am currently writing:
 
   http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/
 
 Concerning file system paths, FilePathEncoder and FilePluginPrimitives 
 already do the right thing.
 
 Now, your idea about using UTF-8 to represent internal Strings is 
 something that has been discussed before and in many other languages as 
 well. The short answer is that due to it being variable length, the 
 inefficiency is (probably) just too high. Simple indexed access becomes a 
 problem, let alone more complex string manipulations. I am not saying that 
 it cannot be done, I think it is just not worth the trouble. The current 
 solution in Pharo with ByteString and WideString is quite nice (check the 
 chapter I mentioned before).
 
 Sven
 
>>> Very interesting !
>>> It seems that most of what I was saying is already here :)
>>> I was not saying that Pharo should use utf8 (I mentionned utf8 because it 
>>> is a standard, but I find the variable length encoding very weird), I was 
>>> rather talking of using WideString in UTF 16 or 32 and that's done.
>>> I saw asWideString but didn't know about automatic convertion or codepoint 
>>> selector and internal wide string support.
>>> Does it means that Pharo Greek users (for example) use WideString for 
>>> Strings without having to specify it or make explicit convertions (except 
>>> of course when dealing with bytes if they want to) ?
>>> If yes, very good, job is almost done :)
>>> (personnally I would also deprecate ByteString, and get rid of it, just my 
>>> opinion).
>>> Thanks for the link, another good chapter .
>>> 
>>> Regards,
>>> 
>>> Alain
>> 
>> ByteString is important because it is an optimalization of the most common 
>> case.
> 
> I understand the point here, memory/data footprint, cpu cache and so on (not 
> talking of encoding/decoding).
> I think that's why Microsoft choosed UTF16 (old UCS2) as a middle solution 
> because it covers most of character sets with 2 bytes.

It used to be a middle solution, back when UCS2 could encode the entire defined 
Unicode set.
Novadays it's just the worst of both worlds; you waste memory for most normal 
text, *and* you don't have constant time indexed code point access.

The duality we have in Pharo is an attempt to achieve the *best* of both 
worlds, wasting little memory for the "normal" case (latin1), and maintain 
constant time indexed access in all cases.
The ultimate solution for this approach would have a trio of string classes 
with slot sizes 8 - 16 - 32 expanding / contracting as needed, but we don't 
have classes with variable short slots. (currently, they're planned in new Cog, 
if I've understood Eliots new object format correctly)

Cheers,
Henry


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-users] Passed by references and by value

[Henrik Johansen]

On 26 Sep 2014, at 8:24 , Marcus Denker  wrote:

> 
> On 25 Sep 2014, at 20:28, Esteban A. Maringolo  wrote:
> 
>> 2014-09-25 15:14 GMT-03:00 nacho <0800na...@gmail.com>:
>>> Hi,
>>> In PBE says that ordinary objects' ivars are passed by references and small
>>> integers are passed by value.
>>> Is there a way to know if a class is passed by reference or by value?
>> 
>>> Only small integers are passed as value?
>> 
>> Yes.
>> 
>> It has to do with the object headers, SmallIntegers are embedded in the OH.
>> 
> 
> In the *reference*, not the header. The reference points to a header for a 
> normal
> object, for small-integers the reference *is* the integer value. This means 
> that
> there is no header for the integers.
> 
>   Marcus

So, a succinct phrasing indifferent to object format, using a relatively 
well-defined term, would be: 
Only immediate objects are passed by value.

(Which means you have to explain immediate objects, as markus did)

Cheers,
Henry


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-users] How to set a white background with Spec ?

[Johan Fabry]

I have not tried this, I just browsed the documentation, but I am putting it 
here as this process usually is the right way to find answers to these 
questions: I looked at the spec class for windows: WindowModel and the 
‘protocol' protocol to see its configuration options. None mention color. I 
looked at the superclass: AbstractWindowModel, and the ‘protocol’ protocol does 
have a color: setter.

So if you have a reference to the WindowModel for the window you are using, you 
should be able to set the color. Please tell me if this works for you. I think 
this question is a good candidate for updating the documentation.

On Sep 26, 2014, at 6:11 AM, Annick Fron  wrote:

> Hi,
> 
>   I am using a window with spec, where can I define a white background 
> for it ?
> 
> Annick
> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-users] invoking python from pharo

[Ben Coman]

kilon alios wrote:
Hi there, I promised to do this a long time ago, but since you asked it 
I done it now. 

So as Ben said I am the author of Ephestos, a communication bridge 
between Blender and Pharo . 

To go directly to the how to . Ephestos is basically a socket bridge 
that send via sockets strings from pharo to python that then python 
executes as python commands. 

Ephestos is made so it works inside blender but I promised Atals a spin 
off project that allows the same socket bridge to be used as a 
standalone. To use do the following. 

1) Get Ephestos , you can find it and install it with the configuration 
browser in your image in Pharo 3 and Pharo 4. Make sure you have a 
recent release though because I added it recently. 

2) Get pyAtlas , this is the python side , you can get it from here 
--> https://github.com/kilon/pyAtlas


3)  in your command line cd to the pyAtlas directory and execute : 
python3 pyAtlas.py


4) in Pharo you can now try any python code you want 


for example

Ephestos sendMessage: 'print("hello world")'.
Ephestos sendMessage: 'x = 3'.
x := Ephestos getValue: 'x'.
x inspect.

Ephestos sendMessage: string, basically sends the python command to be 
executes while getValue: sends the command and returns a value as a string. 

you can use string 'exit' to close the socket bridge but this part is 
buggy as it seems to keep the binding of the sokcet active and I have to 
wait to clean it up in macos to reopen the bridge. 

You can also use pharo syntax and python errors will trigger the pharo 
debugger with a title the python error itself. 

You can find more information about Ephestos in my gitbook that can be 
read here


https://www.gitbook.io/book/kilon/ephestos

Also I forgot to add that sendMessage can send multiline strings , so 
its possible to send python class definitions and other stuff, you type 
the string exactly as you would type python code respecting whitespaces. 
If you want to execute loads of lines of python code then it would be 
better to put your code in a python module and do 

Ephestos sendMessage: 'import mymodule'  

assuming your module is called 'mymodule' , python import basically are 
executions of code. 

If you have any questions just ask. 

Bare in mind this is a socket bridge so its not ideal for sending 
thousands of messages per second and you may run into the occasional bug 
or two which I will fix if you report it. Nonetheless it should allow 
you to execute any kind of code and not just call python functions or 
python methods.




On Thu, Sep 25, 2014 at 7:40 PM, Ben Coman > wrote:


__
Pablo R. Digonzelli wrote:

Hi all , I need to invoke python rutines from Pharo. I need some
orientation about the best way to do it.
TIA



*Ing. Pablo Digonzelli*
Software Solutions
IP-Solutiones SRL
Metrotec SRL
25 de Mayo 521
Email: pdigonze...@softsargentina.com

pdigonze...@gmail.com 
Cel: 5493815982714


Search the [pharo-dev] list for Ephestos by kilon.
cheers -ben




I was going to say... "invoking python from Pharo" with Ephestos/Atlas 
would make a good chapter for Pharo For The Enterprise, but that book is 
actually pretty full.  With other things like OSWindow and SDL coming 
along, I wonder if there might be a new book called "Phoreign Pharo" to 
accumulate solutions to access the world outside the Image.

cheers -ben

Re: [Pharo-users] Your picture on Pharo contributors :)

[Ben Coman]

Trygve Reenskaug wrote:
  With all due respect, I am reluctant to sign this agreement. It 
commits me to whatever might be published at the given URL at any time 
in the future.  I wonder why you didn't make the agreement concrete by 
copying the current text into it?


And I thought that I paid attention to these things, but I never noticed 
this.  I think this sounds reasonable, and indeed beneficial.

cheers -ben



Current contents of :

"Copyright (c)  

Permission is hereby granted, free of charge, to any person
obtaining a copy
 of this software and associated documentation files (the
"Software"), to deal
 in the Software without restriction, including without limitation
the rights
 to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be
included in
 all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
 THE SOFTWARE."

I have no problem with signing this, but I have a problem with signing a 
carte blanche.

--Trygve



On 26.09.2014 07:25, stepharo wrote:

Hi guys

do not forget to sign the license agreement
http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf
and send us your picture to be added to
http://pharo.org/about

Stef







--

Trygve Reenskaug  mailto: tryg...@ifi.uio.no
Morgedalsvn. 5A   http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27

Re: [Pharo-users] invoking python from pharo

[kilon alios]

well in my case that wont be necessary since Ephestos has its own book and
I will keep documenting the more features I add.  I am also thinking of
dropping external documentation and bringing it inside the image. If PFTE
is near completion then most likely will be a next book but I decided to
concentrate more on my own project . I started ambitious with this project
but now I want to make something smaller, easier and more practical for my
personal needs as a 3d artist.

On Fri, Sep 26, 2014 at 4:58 PM, Ben Coman  wrote:

> kilon alios wrote:
>
>> Hi there, I promised to do this a long time ago, but since you asked it I
>> done it now.
>> So as Ben said I am the author of Ephestos, a communication bridge
>> between Blender and Pharo .
>> To go directly to the how to . Ephestos is basically a socket bridge that
>> send via sockets strings from pharo to python that then python executes as
>> python commands.
>> Ephestos is made so it works inside blender but I promised Atals a spin
>> off project that allows the same socket bridge to be used as a standalone.
>> To use do the following.
>> 1) Get Ephestos , you can find it and install it with the configuration
>> browser in your image in Pharo 3 and Pharo 4. Make sure you have a recent
>> release though because I added it recently.
>> 2) Get pyAtlas , this is the python side , you can get it from here -->
>> https://github.com/kilon/pyAtlas
>>
>> 3)  in your command line cd to the pyAtlas directory and execute :
>> python3 pyAtlas.py
>>
>> 4) in Pharo you can now try any python code you want
>> for example
>>
>> Ephestos sendMessage: 'print("hello world")'.
>> Ephestos sendMessage: 'x = 3'.
>> x := Ephestos getValue: 'x'.
>> x inspect.
>>
>> Ephestos sendMessage: string, basically sends the python command to be
>> executes while getValue: sends the command and returns a value as a string.
>> you can use string 'exit' to close the socket bridge but this part is
>> buggy as it seems to keep the binding of the sokcet active and I have to
>> wait to clean it up in macos to reopen the bridge.
>> You can also use pharo syntax and python errors will trigger the pharo
>> debugger with a title the python error itself.
>> You can find more information about Ephestos in my gitbook that can be
>> read here
>>
>> https://www.gitbook.io/book/kilon/ephestos
>>
>> Also I forgot to add that sendMessage can send multiline strings , so its
>> possible to send python class definitions and other stuff, you type the
>> string exactly as you would type python code respecting whitespaces. If you
>> want to execute loads of lines of python code then it would be better to
>> put your code in a python module and do
>> Ephestos sendMessage: 'import mymodule'
>> assuming your module is called 'mymodule' , python import basically are
>> executions of code.
>> If you have any questions just ask.
>> Bare in mind this is a socket bridge so its not ideal for sending
>> thousands of messages per second and you may run into the occasional bug or
>> two which I will fix if you report it. Nonetheless it should allow you to
>> execute any kind of code and not just call python functions or python
>> methods.
>>
>>
>>
>> On Thu, Sep 25, 2014 at 7:40 PM, Ben Coman > b...@openinworld.com>> wrote:
>>
>> __
>> Pablo R. Digonzelli wrote:
>>
>>> Hi all , I need to invoke python rutines from Pharo. I need some
>>> orientation about the best way to do it.
>>> TIA
>>>
>>> 
>>> 
>>> 
>>> *Ing. Pablo Digonzelli*
>>> Software Solutions
>>> IP-Solutiones SRL
>>> Metrotec SRL
>>> 25 de Mayo 521
>>> Email: pdigonze...@softsargentina.com
>>> 
>>> pdigonze...@gmail.com 
>>> Cel: 5493815982714
>>>
>>
>> Search the [pharo-dev] list for Ephestos by kilon.
>> cheers -ben
>>
>>
>>
> I was going to say... "invoking python from Pharo" with Ephestos/Atlas
> would make a good chapter for Pharo For The Enterprise, but that book is
> actually pretty full.  With other things like OSWindow and SDL coming
> along, I wonder if there might be a new book called "Phoreign Pharo" to
> accumulate solutions to access the world outside the Image.
> cheers -ben
>
>

Re: [Pharo-users] How to set a white background with Spec ?

[Nicolai Hess]

Changes on a widget attributes can be defined when it is build.
To hook into this, use #whenBuiltDo:

|t|
t:= TextModel new.
t whenBuiltDo:[:a | a widget color: Color gray].
t openWithSpec.





2014-09-26 15:51 GMT+02:00 Johan Fabry :

>
> I have not tried this, I just browsed the documentation, but I am putting
> it here as this process usually is the right way to find answers to these
> questions: I looked at the spec class for windows: WindowModel and the
> ‘protocol' protocol to see its configuration options. None mention color. I
> looked at the superclass: AbstractWindowModel, and the ‘protocol’ protocol
> does have a color: setter.
>
> So if you have a reference to the WindowModel for the window you are
> using, you should be able to set the color. Please tell me if this works
> for you. I think this question is a good candidate for updating the
> documentation.
>
> On Sep 26, 2014, at 6:11 AM, Annick Fron  wrote:
>
> > Hi,
> >
> >   I am using a window with spec, where can I define a white
> background for it ?
> >
> > Annick
> >
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
>
>
>

Re: [Pharo-users] Passed by references and by value

[Alexandre Bergel]

Indeed, one should not care about copy by value / reference in Pharo.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Sep 25, 2014, at 4:52 PM, stepharo  wrote:

> 
>> Hi,
>> In PBE says that ordinary objects' ivars are passed by references and small
>> integers are passed by value.
> 
> Strange I do not remember having written that.
> Especially because in Smalltalk this has no real interest.
> 
>> Is there a way to know if a class is passed by reference or by value?
> In Smalltalk consider that everything is an object and that you pass a 
> reference to the object.
>> Only small integers are passed as value?
>> Thanks in advance
>> Nacho
>> 
>> 
>> 
>> 
>> 
>> -
>> Nacho
>> Smalltalker apprentice.
>> Buenos Aires, Argentina.
>> --
>> View this message in context: 
>> http://forum.world.st/Passed-by-references-and-by-value-tp4780289.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>> 
>> 
> 
> 

[Pharo-users] Hash values

[Alexandre Bergel]

Hi!

Alejandro and I are working on a new profiling technique to identify redundant 
objects.

We’ve heard there are some effort on increasing the range of identity hash 
values. Currently, it goes up to 4096, which is not much. Can someone tell us 
about this?

Also, I discovered that -100 hash = -100. Does this make sense?

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-users] Ridiculous we are

[stepharo]

I'm not expert and I would like to know what people think.
But I think that we should consider

- the impact of spur new object format. I would like to have 
unicode and clean the leadChar


Stef

Re: [Pharo-users] Ridiculous we are

[stepharo]

Sven I love this chapter.
I will read it calmly now.

Stef

On 25/9/14 07:23, Sven Van Caekenberghe wrote:

On 25 Sep 2014, at 01:04, Alain Rastoul  wrote:


Le 25/09/2014 00:06, Sven Van Caekenberghe a écrit :

Alain,
The character encoding situation in Pharo is pretty good actually. The only 
problem is that there is some old school code left that encodes strings into 
strings, but today you can easily write much better and conceptually correct 
code.

You could have a look at this draft chapter of the upcoming 'Enterprise Pharo' 
book that I am currently writing:

   http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/

Concerning file system paths, FilePathEncoder and FilePluginPrimitives already 
do the right thing.

Now, your idea about using UTF-8 to represent internal Strings is something 
that has been discussed before and in many other languages as well. The short 
answer is that due to it being variable length, the inefficiency is (probably) 
just too high. Simple indexed access becomes a problem, let alone more complex 
string manipulations. I am not saying that it cannot be done, I think it is 
just not worth the trouble. The current solution in Pharo with ByteString and 
WideString is quite nice (check the chapter I mentioned before).

Sven


Very interesting !
It seems that most of what I was saying is already here :)
I was not saying that Pharo should use utf8 (I mentionned utf8 because it is a 
standard, but I find the variable length encoding very weird), I was rather 
talking of using WideString in UTF 16 or 32 and that's done.
I saw asWideString but didn't know about automatic convertion or codepoint 
selector and internal wide string support.
Does it means that Pharo Greek users (for example) use WideString for Strings 
without having to specify it or make explicit convertions (except of course 
when dealing with bytes if they want to) ?
If yes, very good, job is almost done :)
(personnally I would also deprecate ByteString, and get rid of it, just my 
opinion).
Thanks for the link, another good chapter .

Regards,

Alain

Yes, the Greek users won't notice a difference, it is all transparent. 
ByteString is important because it is an optimalization of the most common 
case. As a normal user you should only think of abstract Strings and never use 
#asByteString (but use proper encoding).

Feedback on the chapter is always welcome.

Sven

Re: [Pharo-users] Ridiculous we are

[p...@highoctane.be]

I'd love another title for this thread.

It depresses me.

Phil

On Fri, Sep 26, 2014 at 8:48 PM, stepharo  wrote:

> Sven I love this chapter.
> I will read it calmly now.
>
> Stef
>
> On 25/9/14 07:23, Sven Van Caekenberghe wrote:
>
>> On 25 Sep 2014, at 01:04, Alain Rastoul  wrote:
>>
>>  Le 25/09/2014 00:06, Sven Van Caekenberghe a écrit :
>>>
 Alain,
 The character encoding situation in Pharo is pretty good actually. The
 only problem is that there is some old school code left that encodes
 strings into strings, but today you can easily write much better and
 conceptually correct code.

 You could have a look at this draft chapter of the upcoming 'Enterprise
 Pharo' book that I am currently writing:

http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/

 Concerning file system paths, FilePathEncoder and FilePluginPrimitives
 already do the right thing.

 Now, your idea about using UTF-8 to represent internal Strings is
 something that has been discussed before and in many other languages as
 well. The short answer is that due to it being variable length, the
 inefficiency is (probably) just too high. Simple indexed access becomes a
 problem, let alone more complex string manipulations. I am not saying that
 it cannot be done, I think it is just not worth the trouble. The current
 solution in Pharo with ByteString and WideString is quite nice (check the
 chapter I mentioned before).

 Sven

  Very interesting !
>>> It seems that most of what I was saying is already here :)
>>> I was not saying that Pharo should use utf8 (I mentionned utf8 because
>>> it is a standard, but I find the variable length encoding very weird), I
>>> was rather talking of using WideString in UTF 16 or 32 and that's done.
>>> I saw asWideString but didn't know about automatic convertion or
>>> codepoint selector and internal wide string support.
>>> Does it means that Pharo Greek users (for example) use WideString for
>>> Strings without having to specify it or make explicit convertions (except
>>> of course when dealing with bytes if they want to) ?
>>> If yes, very good, job is almost done :)
>>> (personnally I would also deprecate ByteString, and get rid of it, just
>>> my opinion).
>>> Thanks for the link, another good chapter .
>>>
>>> Regards,
>>>
>>> Alain
>>>
>> Yes, the Greek users won't notice a difference, it is all transparent.
>> ByteString is important because it is an optimalization of the most common
>> case. As a normal user you should only think of abstract Strings and never
>> use #asByteString (but use proper encoding).
>>
>> Feedback on the chapter is always welcome.
>>
>> Sven
>>
>>
>
>
>

Re: [Pharo-users] Hash values

[stepharo]

Hi!

Alejandro and I are working on a new profiling technique to identify 
redundant objects.


We’ve heard there are some effort on increasing the range of identity 
hash values. Currently, it goes up to 4096, which is not much. Can 
someone tell us about this?
Check the spur format on clement's blog. If I remember we will have 12 
bits for hashes soon.


Also, I discovered that -100 hash = -100. Does this make sense?

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-users] Ridiculous we are

[Hilaire]

Le 26/09/2014 21:00, p...@highoctane.be a écrit :
> I'd love another title for this thread.
> 
> It depresses me.

Yes, me too.

Hilaire

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

Re: [Pharo-users] Hash values

[Alexandre Bergel]

Yeah!!!
That would be really cool!

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Sep 26, 2014, at 4:02 PM, stepharo  wrote:

> 
>> Hi!
>> 
>> Alejandro and I are working on a new profiling technique to identify 
>> redundant objects.
>> 
>> We’ve heard there are some effort on increasing the range of identity hash 
>> values. Currently, it goes up to 4096, which is not much. Can someone tell 
>> us about this?
> Check the spur format on clement's blog. If I remember we will have 12 bits 
> for hashes soon.
>> 
>> Also, I discovered that -100 hash = -100. Does this make sense?
>> 
>> Cheers,
>> Alexandre
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
> 

[Pharo-users] Unicode support in Pharo

[Alain Rastoul]

Le 26/09/2014 20:47, stepharo a écrit :

I'm not expert and I would like to know what people think.
But I think that we should consider

 - the impact of spur new object format. I would like to have
unicode and clean the leadChar

Stef



Just to start a new thread about that, because it deserves it
and also some people might appreciate :)
(was in: "Ridiculous we are").

I may not be the most qualified to state on that but I give my 2c
(this is a community isn't it ? please do not flame...)

As Sven said, the situation is not so bad (quite good in fact): Pharo 
has true unicode built-in support with WideString and encoders (great 
job, IMHO this part of Zn components should be in the base system
or in an internationalization package  not hidden in an htpp components 
package).
- encoding support has to be in the system : ZnEncoders(?) for utf8, 
unicode and other encoders for locale support because of existing 
system basis, web (utf8) and internationalization.
- this will be transparent: Smalltalk is a typeless langage, one do not 
have to specify String type (ByteString or WideString)
- Spur new character encoding is very interesting (in alpha stage now) 
and will be transparent for the same reason (though I'm still wondering 
of the 32bits/64 bits encoding on a 64 bits vm?).
- ByteString is needed for most european/occidental people who don't 
care about internationalization and should stay because Pharo is an 
european/english based system , also not to break existing code

(again will be transparent to most users for same reason).
- some parts of the system seems to be not "WideString/unicode aware" :
Pasting a Greek string in a workspace shows hieroglyphs (editors? 
morph?), but GT Inspector display is ok.
Font plugin seems to require little work : uses fopen instead of _wfopen 
(utf16 version) on windows and needs utf8 convertion on unix.
may be a check with File plugin (and other system related plugins) is 
also needed?


In short, some little additionnal work but a very good basis.
(but what is leadChar about?)

Regards,

Alain

Re: [Pharo-users] Unicode support in Pharo

[Alain Rastoul]

Le 26/09/2014 23:22, Alain Rastoul a écrit :

Le 26/09/2014 20:47, stepharo a écrit :

I'm not expert and I would like to know what people think.
But I think that we should consider

 - the impact of spur new object format. I would like to have
unicode and clean the leadChar

Stef



Just to start a new thread about that, because it deserves it
and also some people might appreciate :)
(was in: "Ridiculous we are").

I may not be the most qualified to state on that but I give my 2c
(this is a community isn't it ? please do not flame...)

As Sven said, the situation is not so bad (quite good in fact): Pharo
has true unicode built-in support with WideString and encoders (great
job, IMHO this part of Zn components should be in the base system
or in an internationalization package  not hidden in an htpp components
package).
- encoding support has to be in the system : ZnEncoders(?) for utf8,
unicode and other encoders for locale support because of existing system
basis, web (utf8) and internationalization.
- this will be transparent: Smalltalk is a typeless langage, one do not
have to specify String type (ByteString or WideString)
- Spur new character encoding is very interesting (in alpha stage now)
and will be transparent for the same reason (though I'm still wondering
of the 32bits/64 bits encoding on a 64 bits vm?).
- ByteString is needed for most european/occidental people who don't
care about internationalization and should stay because Pharo is an
european/english based system , also not to break existing code
(again will be transparent to most users for same reason).
- some parts of the system seems to be not "WideString/unicode aware" :
Pasting a Greek string in a workspace shows hieroglyphs (editors?
morph?), but GT Inspector display is ok.
Font plugin seems to require little work : uses fopen instead of _wfopen
(utf16 version) on windows and needs utf8 convertion on unix.
may be a check with File plugin (and other system related plugins) is
also needed?

In short, some little additionnal work but a very good basis.
(but what is leadChar about?)

Regards,

Alain




This was not a new thread indeed, I did "respond to group"
I am ridiculous ... hahaha
:)

Re: [Pharo-users] Unicode support in Pharo

[Sven Van Caekenberghe]

On 26 Sep 2014, at 23:22, Alain Rastoul  wrote:

> Pasting a Greek string in a workspace shows hieroglyphs (editors? morph?), 
> but GT Inspector display is ok.

That is a font issue. Check your font settings in the Settings Browser.

Like I mentioned in the chapter, you could try to use 'Arial Unicode MS'.

I would guess you use Source Code Pro for code panes (like the workspace) and 
Open Sans for the rest. Source Code Pro has limited Unicode support. GT 
probably uses only Open Sans.

Re: [Pharo-users] Unicode support in Pharo

[Alain Rastoul]

Le 27/09/2014 01:02, Sven Van Caekenberghe a écrit :


On 26 Sep 2014, at 23:22, Alain Rastoul  wrote:


Pasting a Greek string in a workspace shows hieroglyphs (editors? morph?), but 
GT Inspector display is ok.


That is a font issue. Check your font settings in the Settings Browser.

Like I mentioned in the chapter, you could try to use 'Arial Unicode MS'.

I would guess you use Source Code Pro for code panes (like the workspace) and 
Open Sans for the rest. Source Code Pro has limited Unicode support. GT 
probably uses only Open Sans.

Ouch, forgot about different font settings for morphic elements, and 
evident, GTInspector could not display correctly if editor would not 
deal with WideString (forgot about bytestring/widestring transparency?).
BTW I do not have Arial unicode MS on my system, it comes with MS 
Office, but Deja Vu and Bitmap Deja vu display some Greek chars correctly.

Re: [Pharo-users] Your picture on Pharo contributors :)

[stepharo]

Trygve

We took exactly the same license process and text than squeak. This way 
people cannot argue that this is different
because pharo is based on Squeak. It took squeak a large effort to 
relicense the code and we rewrote missing methods

double blind to get clean.

Stef


On 26/9/14 10:19, Trygve Reenskaug wrote:
With all due respect, I am reluctant to sign this agreement. It 
commits me to whatever might be published at the given URL at any time 
in the future.  I wonder why you didn't make the agreement concrete by 
copying the current text into it?


Current contents of :

"Copyright (c)  

Permission is hereby granted, free of charge, to any person
obtaining a copy
 of this software and associated documentation files (the
"Software"), to deal
 in the Software without restriction, including without limitation
the rights
 to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be
included in
 all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
 THE SOFTWARE."

I have no problem with signing this, but I have a problem with signing 
a carte blanche.

--Trygve



On 26.09.2014 07:25, stepharo wrote:

Hi guys

do not forget to sign the license agreement
http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf
and send us your picture to be added to
http://pharo.org/about

Stef







--

Trygve Reenskaug  mailto: tryg...@ifi.uio.no
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27

Re: [Pharo-users] How to set a white background with Spec ?

[stepharo]

One of these days we should do a pass because I do not get why such 
properties are not simply handled by the model.


Stef


Changes on a widget attributes can be defined when it is build.
To hook into this, use #whenBuiltDo:

|t|
t:= TextModel new.
t whenBuiltDo:[:a | a widget color: Color gray].
t openWithSpec.





2014-09-26 15:51 GMT+02:00 Johan Fabry >:



I have not tried this, I just browsed the documentation, but I am
putting it here as this process usually is the right way to find
answers to these questions: I looked at the spec class for
windows: WindowModel and the ‘protocol' protocol to see its
configuration options. None mention color. I looked at the
superclass: AbstractWindowModel, and the ‘protocol’ protocol does
have a color: setter.

So if you have a reference to the WindowModel for the window you
are using, you should be able to set the color. Please tell me if
this works for you. I think this question is a good candidate for
updating the documentation.

On Sep 26, 2014, at 6:11 AM, Annick Fron mailto:l...@afceurope.com>> wrote:

> Hi,
>
>   I am using a window with spec, where can I define a white
background for it ?
>
> Annick
>



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   - http://pleiad.cl/~jfabry 
PLEIAD lab  -  Computer Science Department (DCC)  - University of
Chile

[Pharo-users] Hanging reference and sluggish image

[Alain Rastoul]

Hi,

I have a sluggish image due to some hanging reference on a big object (a 
BTree filled with test data) that I inspected with GTInspector, and 
can't get rid of those references.
Opening a PointerExplorer on this object show me lot of various 
references from GLMCompositePresentations,

GLMPanes, AnouncementSubscriptions, blocks etc.
Is there a clean way to reset subscriptions , announcers and 
GLMPresentations ?


Any help or suggestion will be greatly appreciated,

thanks in advance,

Alain