Re: [Pharo-dev] [Pharo-users] Startup preferences

[Stéphane Ducasse]

:)

Stef

On Jun 24, 2013, at 4:22 AM, Mariano Martinez Peck  
wrote:

> Cool! Thanks Stef. I just add an update in the blog post mentioning the 
> chapter pdf :)
> 
> 
> On Sun, Jun 23, 2013 at 5:36 PM, Stéphane Ducasse  
> wrote:
> Hi guys
> 
> I realised that I did not know well the startup preferences which is really 
> cool :)
> I read and converted (updated and enhanced) the blog of Mariano (thanks for 
> that Mariano).
> Now I want to share a new chapter with you.
> 
> StartupPreferences.pier.pdf
> 
> Enjoy :)
> Thanks Benjamin and Mariano. 
> 
> 
> Stef 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-dev] [Pharo-users] Startup preferences

[Mariano Martinez Peck]

Cool! Thanks Stef. I just add an update in the blog post mentioning the
chapter pdf :)


On Sun, Jun 23, 2013 at 5:36 PM, Stéphane Ducasse  wrote:

> Hi guys
>
> I realised that I did not know well the startup preferences which is
> really cool :)
> I read and converted (updated and enhanced) the blog of Mariano (thanks
> for that Mariano).
> Now I want to share a new chapter with you.
>
> StartupPreferences.pier.pdf
>
> Enjoy :)
> Thanks Benjamin and Mariano.
>
>
> Stef
>



-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Stéphane Ducasse]

Nicolas told me that he spent a day last week fixing some smalltalkhub bugs.
May be this is one is part of it.


On Jun 23, 2013, at 10:28 PM, Sven Van Caekenberghe  wrote:

> This is a typical, understandable problem. I had the same problem with my 
> http://mc.stfx.eu Monticello repos once. The thing is that
> 
> http://smalltalkhub.com/mc/dkh/metacello/main
> 
> should redirect to
> 
> http://smalltalkhub.com/mc/dkh/metacello/main/
> 
> not just serve the same content, because else the relative links are all 
> wrong.
> 
> You can try
> 
> http://mc.stfx.eu/ZincHTTPComponents
> 
> to see how it should work.
> 
> And yes this is a StHub bug that can be fixed quite easily.
> 
> Sven
> 
> On 23 Jun 2013, at 22:04, "Dale K. Henrichs" 
>  wrote:
> 
>> 
>> 
>> - Original Message -
>> | From: "Camillo Bruni" 
>> | To: "Pharo Development List" 
>> | Sent: Sunday, June 23, 2013 12:53:44 PM
>> | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on  
>> smalltalkhub?
>> | 
>> | 
>> | On 2013-06-23, at 21:48, "Dale K. Henrichs"
>> |  wrote:
>> | 
>> | > Cami,
>> | > 
>> | > Did you confirm that smalltalkhub is producing incorrect urls?
>> | 
>> | if you omit the trailing slash and click on a link of the version
>> | list in a browser, then yes.
>> | 
>> 
>> Cami,
>> 
>> Smalltalkhub itself omits the trailing slash[1]:
>> 
>> MCHttpRepository
>>  location: 'http://smalltalkhub.com/mc/dkh/metacello/main'
>>  user: 'dkh'
>>  password: ''
>> 
>> That's probably where I copied the link from to look at the full list of 
>> packages ... 
>> 
>> _I_ didn't do the omitting:)
>> 
>> Dale
>> 
>> [1] http://smalltalkhub.com/#!/~dkh/metacello
>> 
> 
> 

Re: [Pharo-dev] Object >> #is:

[Stéphane Ducasse]

On Jun 23, 2013, at 10:08 PM, Tudor Girba  wrote:

> Just remove it :)

I do not really like to have extra symbol not directly connected to their 
classes.
I understand the idea behind is: but …. 

> Doru
> 
> 
> On Sun, Jun 23, 2013 at 9:44 PM, Camillo Bruni  wrote:
> 
> On 2013-06-23, at 21:40, Tudor Girba  wrote:
> 
> > Actually, a better implementation would be:
> >
> > Object>>is: aClassOrSymbol
> > ^ aClassOrSymbol asString = self class name asString
> 
> 
> 
> > Like this you can even pass the class instead of its name (I presume that
> > printOn: will not change any time soon so we can rely on the fact that we
> > can polymorphically obtain the name of the class via asString).
> 
> 
> ... and we're starting from scratch again, sorry, I spent too much time 
> discussing
> this already :P
> 
> => I am very much against comparing strings, this just doesn't scale
> 
> 
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"

[Pharo-dev] Startup preferences

[Stéphane Ducasse]

Hi guys

I realised that I did not know well the startup preferences which is really 
cool :)
I read and converted (updated and enhanced) the blog of Mariano (thanks for 
that Mariano).
Now I want to share a new chapter with you.

StartupPreferences.pier.pdf

Enjoy :)
Thanks Benjamin and Mariano. 


Stef 

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Sven Van Caekenberghe]

This is a typical, understandable problem. I had the same problem with my 
http://mc.stfx.eu Monticello repos once. The thing is that

http://smalltalkhub.com/mc/dkh/metacello/main

should redirect to

http://smalltalkhub.com/mc/dkh/metacello/main/

not just serve the same content, because else the relative links are all wrong.

You can try

http://mc.stfx.eu/ZincHTTPComponents

to see how it should work.

And yes this is a StHub bug that can be fixed quite easily.

Sven

On 23 Jun 2013, at 22:04, "Dale K. Henrichs"  
wrote:

> 
> 
> - Original Message -
> | From: "Camillo Bruni" 
> | To: "Pharo Development List" 
> | Sent: Sunday, June 23, 2013 12:53:44 PM
> | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz  missing on  
> smalltalkhub?
> | 
> | 
> | On 2013-06-23, at 21:48, "Dale K. Henrichs"
> |  wrote:
> | 
> | > Cami,
> | > 
> | > Did you confirm that smalltalkhub is producing incorrect urls?
> | 
> | if you omit the trailing slash and click on a link of the version
> | list in a browser, then yes.
> | 
> 
> Cami,
> 
> Smalltalkhub itself omits the trailing slash[1]:
> 
>  MCHttpRepository
>   location: 'http://smalltalkhub.com/mc/dkh/metacello/main'
>   user: 'dkh'
>   password: ''
> 
> That's probably where I copied the link from to look at the full list of 
> packages ... 
> 
> _I_ didn't do the omitting:)
> 
> Dale
> 
> [1] http://smalltalkhub.com/#!/~dkh/metacello
> 

Re: [Pharo-dev] Object >> #is:

[Tudor Girba]

Just remove it :)

Doru


On Sun, Jun 23, 2013 at 9:44 PM, Camillo Bruni wrote:

>
> On 2013-06-23, at 21:40, Tudor Girba  wrote:
>
> > Actually, a better implementation would be:
> >
> > Object>>is: aClassOrSymbol
> > ^ aClassOrSymbol asString = self class name asString
>
>
>
> > Like this you can even pass the class instead of its name (I presume that
> > printOn: will not change any time soon so we can rely on the fact that we
> > can polymorphically obtain the name of the class via asString).
>
>
> ... and we're starting from scratch again, sorry, I spent too much time
> discussing
> this already :P
>
> => I am very much against comparing strings, this just doesn't scale
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Dale K. Henrichs]

- Original Message -
| From: "Camillo Bruni" 
| To: "Pharo Development List" 
| Sent: Sunday, June 23, 2013 12:53:44 PM
| Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mczmissing on  
smalltalkhub?
| 
| 
| On 2013-06-23, at 21:48, "Dale K. Henrichs"
|  wrote:
| 
| > Cami,
| > 
| > Did you confirm that smalltalkhub is producing incorrect urls?
| 
| if you omit the trailing slash and click on a link of the version
| list in a browser, then yes.
| 

Cami,

Smalltalkhub itself omits the trailing slash[1]:

  MCHttpRepository
location: 'http://smalltalkhub.com/mc/dkh/metacello/main'
user: 'dkh'
password: ''

That's probably where I copied the link from to look at the full list of 
packages ... 

_I_ didn't do the omitting:)

Dale

[1] http://smalltalkhub.com/#!/~dkh/metacello

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Dale K. Henrichs]

- Original Message -
| From: "Camillo Bruni" 
| To: "Pharo Development List" 
| Sent: Sunday, June 23, 2013 12:46:03 PM
| Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missingon  
smalltalkhub?
| 
| rewind,
| what exactly are you doing?
| in which image?
| 
| 
| => the listing has some issues with the relative links, AFAIK that
| has also been there for a while

? 

I got an EOCD error loading Metacello-ToolBox-dkh.131 into GemStone during a 
travis ci job[2]... 

A month ago I reported a bug[1] and figured that the error was possibly related 
so I went to the site and used the 
http://smalltalkhub.com/mc/dkh/metacello/main/ url to look at the available 
packages (like I do with all of the other mcz repositories) to confirm that the 
package was there and that it was not corrupted  ... when they all turned up 
giving me errors I figured that something else was broken and sent the mail ... 

I didn't realize that this listing has always been broken in smalltalkhub ... 

The EOCD error was  probably just a transient problem and I was fooled into 
thinking that the site was truly broken ... sorry about that...

Dale

[1] https://code.google.com/p/smalltalk-hub/issues/detail?id=21
[2] https://travis-ci.org/glassdb/glass/jobs/8366726#L546
[3] https://travis-ci.org/glassdb/glass/jobs/8366726#L546

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Camillo Bruni]

On 2013-06-23, at 21:48, "Dale K. Henrichs"  
wrote:

> Cami,
> 
> Did you confirm that smalltalkhub is producing incorrect urls?

if you omit the trailing slash and click on a link of the version list in a 
browser, then yes.

> - Original Message -
> | From: "Camillo Bruni" 
> | To: "Pharo Development List" 
> | Sent: Sunday, June 23, 2013 12:46:03 PM
> | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing  on  
> smalltalkhub?
> | 
> | rewind,
> | what exactly are you doing?
> | in which image?
> | 
> | 
> | => the listing has some issues with the relative links, AFAIK that
> | has also been there for a while
> | doing adding a trailing slash usually solves this problem:
> | 
> | http://smalltalkhub.com/mc/dkh/metacello/main/
> | 
> | On 2013-06-23, at 21:39, "Dale K. Henrichs"
> |  wrote:
> | > I didn't forget the main part ... the url supplied by the listing
> | > at:
> | > 
> | >  http://smalltalkhub.com/mc/dkh/metacello/main
> | > 
> | > is leaving 'main' off...
> | > 
> | > Dale
> | > 
> | > - Original Message -
> | > | From: "Camillo Bruni" 
> | > | To: "Pharo Development List" 
> | > | Sent: Sunday, June 23, 2013 12:36:55 PM
> | > | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on
> | > | smalltalkhub?
> | > | 
> | > | its here: http://smalltalkhub.com/mc/dkh/metacello/main
> | > | 
> | > | => you forgot the /main part
> | > | 
> | > | On 2013-06-23, at 21:32, "Dale K. Henrichs"
> | > |  wrote:
> | > | 
> | > | > When I use the following url:
> | > | > 
> | > | >  
> http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
> | > | > 
> | > | > I get:
> | > | > 
> | > | >  /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found
> | > | > 
> | > | > 
> | > | > instead of my package downloaded ... the mcz file used to be
> | > | > there
> | > | > and it does show up in the listing for
> | > | > 
> | > | >  http://smalltalkhub.com/mc/dkh/metacello/main
> | > | > 
> | > | > the repository ... In fact none of the packages  in the
> | > | > metacello
> | > | > repository are accessible...
> | > | > 
> | > | > Part of the site must down?
> | > | > 
> | > | > 
> | > | > Dale
> | > | > 
> | > | > 
> | > | 
> | > | 
> | > | 
> | > 
> | 
> | 
> | 
> 

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Dale K. Henrichs]

Cami,

Did you confirm that smalltalkhub is producing incorrect urls?

Dale

- Original Message -
| From: "Camillo Bruni" 
| To: "Pharo Development List" 
| Sent: Sunday, June 23, 2013 12:46:03 PM
| Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missingon  
smalltalkhub?
| 
| rewind,
| what exactly are you doing?
| in which image?
| 
| 
| => the listing has some issues with the relative links, AFAIK that
| has also been there for a while
| doing adding a trailing slash usually solves this problem:
| 
| http://smalltalkhub.com/mc/dkh/metacello/main/
| 
| On 2013-06-23, at 21:39, "Dale K. Henrichs"
|  wrote:
| > I didn't forget the main part ... the url supplied by the listing
| > at:
| > 
| >  http://smalltalkhub.com/mc/dkh/metacello/main
| > 
| > is leaving 'main' off...
| > 
| > Dale
| > 
| > - Original Message -
| > | From: "Camillo Bruni" 
| > | To: "Pharo Development List" 
| > | Sent: Sunday, June 23, 2013 12:36:55 PM
| > | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on
| > |   smalltalkhub?
| > | 
| > | its here: http://smalltalkhub.com/mc/dkh/metacello/main
| > | 
| > | => you forgot the /main part
| > | 
| > | On 2013-06-23, at 21:32, "Dale K. Henrichs"
| > |  wrote:
| > | 
| > | > When I use the following url:
| > | > 
| > | >  http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
| > | > 
| > | > I get:
| > | > 
| > | >  /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found
| > | > 
| > | > 
| > | > instead of my package downloaded ... the mcz file used to be
| > | > there
| > | > and it does show up in the listing for
| > | > 
| > | >  http://smalltalkhub.com/mc/dkh/metacello/main
| > | > 
| > | > the repository ... In fact none of the packages  in the
| > | > metacello
| > | > repository are accessible...
| > | > 
| > | > Part of the site must down?
| > | > 
| > | > 
| > | > Dale
| > | > 
| > | > 
| > | 
| > | 
| > | 
| > 
| 
| 
| 

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Camillo Bruni]

rewind, 
what exactly are you doing?
in which image?


=> the listing has some issues with the relative links, AFAIK that has also 
been there for a while
doing adding a trailing slash usually solves this problem:

http://smalltalkhub.com/mc/dkh/metacello/main/

On 2013-06-23, at 21:39, "Dale K. Henrichs"  
wrote:
> I didn't forget the main part ... the url supplied by the listing at:
> 
>  http://smalltalkhub.com/mc/dkh/metacello/main
> 
> is leaving 'main' off...
> 
> Dale
> 
> - Original Message -
> | From: "Camillo Bruni" 
> | To: "Pharo Development List" 
> | Sent: Sunday, June 23, 2013 12:36:55 PM
> | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on   
> smalltalkhub?
> | 
> | its here: http://smalltalkhub.com/mc/dkh/metacello/main
> | 
> | => you forgot the /main part
> | 
> | On 2013-06-23, at 21:32, "Dale K. Henrichs"
> |  wrote:
> | 
> | > When I use the following url:
> | > 
> | >  http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
> | > 
> | > I get:
> | > 
> | >  /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found
> | > 
> | > 
> | > instead of my package downloaded ... the mcz file used to be there
> | > and it does show up in the listing for
> | > 
> | >  http://smalltalkhub.com/mc/dkh/metacello/main
> | > 
> | > the repository ... In fact none of the packages  in the metacello
> | > repository are accessible...
> | > 
> | > Part of the site must down?
> | > 
> | > 
> | > Dale
> | > 
> | > 
> | 
> | 
> | 
> 

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Dale K. Henrichs]

Cami,

Pleas just follow my instructions:

  1. go to 'http://smalltalkhub.com/mc/dkh/metacello/main'.
  2. click on any link there 
  3. you will a not found message ... 

The listing is being produced by smalltalkhub not me and the listing is 
incorrect ... this has worked in the past like yesterday..

Dale
- Original Message -
| From: "Camillo Bruni" 
| To: "Pharo Development List" 
| Sent: Sunday, June 23, 2013 12:40:14 PM
| Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on 
smalltalkhub?
| 
| 
| On 2013-06-23, at 21:36, "Dale K. Henrichs"
|  wrote:
| 
| > I can access the mcz file when I go to this url:
| > 
| >  
http://smalltalkhub.com/#!/~dkh/metacello/versions/Metacello-ToolBox-dkh.131
| > 
| > and press the download button ... but trying to download the
| > package to my image with:
| > 
| >  http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
| 
| but this url is wrong, and always was. It should be
| 
| http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-ToolBox-dkh.131.mcz
| 
| check your repository url to see if it includes the /main/ part or
| not.
| 
| > gives me an the not found message.
| > 
| > BTW, this was working not more than an hour ago...
| > 
| > Dale
| > 
| > 
| > - Original Message -
| > | From: "Dale K. Henrichs" 
| > | To: pharo-dev@lists.pharo.org
| > | Sent: Sunday, June 23, 2013 12:32:32 PM
| > | Subject: Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
| > | 
| > | When I use the following url:
| > | 
| > |   http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
| > | 
| > | I get:
| > | 
| > |   /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found
| > | 
| > | 
| > | instead of my package downloaded ... the mcz file used to be
| > | there
| > | and it does show up in the listing for
| > | 
| > |   http://smalltalkhub.com/mc/dkh/metacello/main
| > | 
| > | the repository ... In fact none of the packages  in the metacello
| > | repository are accessible...
| > | 
| > | Part of the site must down?
| > | 
| > | 
| > | Dale
| > | 
| > | 
| > 
| 
| 
| 

Re: [Pharo-dev] Object >> #is:

[Camillo Bruni]

On 2013-06-23, at 21:40, Tudor Girba  wrote:

> Actually, a better implementation would be:
> 
> Object>>is: aClassOrSymbol
> ^ aClassOrSymbol asString = self class name asString



> Like this you can even pass the class instead of its name (I presume that
> printOn: will not change any time soon so we can rely on the fact that we
> can polymorphically obtain the name of the class via asString).


... and we're starting from scratch again, sorry, I spent too much time 
discussing
this already :P

=> I am very much against comparing strings, this just doesn't scale

Re: [Pharo-dev] why so many processes are running at startup time?

[Camillo Bruni]

On 2013-06-23, at 21:02, Sven Van Caekenberghe  wrote:

> Camillo,
> 
> Let's hope you found the problem, make sure to double check with the team 
> over there.
> 
> I added 
> https://pharo.fogbugz.com/f/cases/10998/Add-ReleaseTest-testUnknownProcesses 
> but this might be hard to make work in practice.

I think this is perfectly fine. A freshly shipped image shouldn't have more 
than a 
handful of known processes running...

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Camillo Bruni]

On 2013-06-23, at 21:36, "Dale K. Henrichs"  
wrote:

> I can access the mcz file when I go to this url:
> 
>  http://smalltalkhub.com/#!/~dkh/metacello/versions/Metacello-ToolBox-dkh.131
> 
> and press the download button ... but trying to download the package to my 
> image with:
> 
>  http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz

but this url is wrong, and always was. It should be 

http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-ToolBox-dkh.131.mcz

check your repository url to see if it includes the /main/ part or not.

> gives me an the not found message.
> 
> BTW, this was working not more than an hour ago...
> 
> Dale
> 
> 
> - Original Message -
> | From: "Dale K. Henrichs" 
> | To: pharo-dev@lists.pharo.org
> | Sent: Sunday, June 23, 2013 12:32:32 PM
> | Subject: Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
> | 
> | When I use the following url:
> | 
> |   http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
> | 
> | I get:
> | 
> |   /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found
> | 
> | 
> | instead of my package downloaded ... the mcz file used to be there
> | and it does show up in the listing for
> | 
> |   http://smalltalkhub.com/mc/dkh/metacello/main
> | 
> | the repository ... In fact none of the packages  in the metacello
> | repository are accessible...
> | 
> | Part of the site must down?
> | 
> | 
> | Dale
> | 
> | 
> 

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Dale K. Henrichs]

I didn't forget the main part ... the url supplied by the listing at:

  http://smalltalkhub.com/mc/dkh/metacello/main

is leaving 'main' off...

Dale

- Original Message -
| From: "Camillo Bruni" 
| To: "Pharo Development List" 
| Sent: Sunday, June 23, 2013 12:36:55 PM
| Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on 
smalltalkhub?
| 
| its here: http://smalltalkhub.com/mc/dkh/metacello/main
| 
| => you forgot the /main part
| 
| On 2013-06-23, at 21:32, "Dale K. Henrichs"
|  wrote:
| 
| > When I use the following url:
| > 
| >  http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
| > 
| > I get:
| > 
| >  /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found
| > 
| > 
| > instead of my package downloaded ... the mcz file used to be there
| > and it does show up in the listing for
| > 
| >  http://smalltalkhub.com/mc/dkh/metacello/main
| > 
| > the repository ... In fact none of the packages  in the metacello
| > repository are accessible...
| > 
| > Part of the site must down?
| > 
| > 
| > Dale
| > 
| > 
| 
| 
| 

Re: [Pharo-dev] Object >> #is:

[Tudor Girba]

Actually, a better implementation would be:

Object>>is: aClassOrSymbol
 ^ aClassOrSymbol asString = self class name asString

Like this you can even pass the class instead of its name (I presume that
printOn: will not change any time soon so we can rely on the fact that we
can polymorphically obtain the name of the class via asString).

Cheers,
Doru



On Sun, Jun 23, 2013 at 9:30 PM, Camillo Bruni wrote:

>
> On 2013-06-23, at 21:25, Tudor Girba  wrote:
>
> > If we want to have an Object>>is:, why not:
> >
> > Object>>is: aSymbol
> > ^ aSymbol = self class name
> >
> > ?
> >
> > Like this, I do not have to override it unless I need to rely on a
> > different mechanism.
>
> exactly, that is everybody's immediate reaction, except for the method's
> author ;)..
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Dale K. Henrichs]

I can access the mcz file when I go to this url:

  http://smalltalkhub.com/#!/~dkh/metacello/versions/Metacello-ToolBox-dkh.131

and press the download button ... but trying to download the package to my 
image with:

  http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz

gives me an the not found message.

BTW, this was working not more than an hour ago...

Dale


- Original Message -
| From: "Dale K. Henrichs" 
| To: pharo-dev@lists.pharo.org
| Sent: Sunday, June 23, 2013 12:32:32 PM
| Subject: Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
| 
| When I use the following url:
| 
|   http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
| 
| I get:
| 
|   /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found
| 
| 
| instead of my package downloaded ... the mcz file used to be there
| and it does show up in the listing for
| 
|   http://smalltalkhub.com/mc/dkh/metacello/main
| 
| the repository ... In fact none of the packages  in the metacello
| repository are accessible...
| 
| Part of the site must down?
| 
| 
| Dale
| 
| 

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Camillo Bruni]

its here: http://smalltalkhub.com/mc/dkh/metacello/main

=> you forgot the /main part

On 2013-06-23, at 21:32, "Dale K. Henrichs"  
wrote:

> When I use the following url:
> 
>  http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz
> 
> I get:
> 
>  /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found 
> 
> 
> instead of my package downloaded ... the mcz file used to be there and it 
> does show up in the listing for 
> 
>  http://smalltalkhub.com/mc/dkh/metacello/main
> 
> the repository ... In fact none of the packages  in the metacello repository 
> are accessible...
> 
> Part of the site must down?
> 
> 
> Dale
> 
> 

[Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

[Dale K. Henrichs]

When I use the following url:

  http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz

I get:

  /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found 


instead of my package downloaded ... the mcz file used to be there and it does 
show up in the listing for 

  http://smalltalkhub.com/mc/dkh/metacello/main

the repository ... In fact none of the packages  in the metacello repository 
are accessible...

Part of the site must down?


Dale

Re: [Pharo-dev] Object >> #is:

[Camillo Bruni]

On 2013-06-23, at 21:25, Tudor Girba  wrote:

> If we want to have an Object>>is:, why not:
> 
> Object>>is: aSymbol
> ^ aSymbol = self class name
> 
> ?
> 
> Like this, I do not have to override it unless I need to rely on a
> different mechanism.

exactly, that is everybody's immediate reaction, except for the method's author 
;)..

Re: [Pharo-dev] Object >> #is:

[Tudor Girba]

If we want to have an Object>>is:, why not:

Object>>is: aSymbol
^ aSymbol = self class name

?

Like this, I do not have to override it unless I need to rely on a
different mechanism.

Cheers,
Doru




On Sun, Jun 23, 2013 at 8:18 PM, Camillo Bruni wrote:

>
> On 2013-06-23, at 19:19, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
> > Except that if an object both is: this and is: that, from two different
> > packages, this will lead to an override.
>
> from which package? #is: doesn't seem to be used in general
>
> > 2013/6/23 Sven Van Caekenberghe 
> >
> >>
> >> On 23 Jun 2013, at 18:14, Camillo Bruni  wrote:
> >>
> >>> can we remove that, or is this still in use?
> >>
> >> Hmm, no senders, no implementors, but the idea is not bad: it could
> >> replace a lot of methods. And it bears the signature of some illustrious
> >> hackers…
> >>
> >> Sven
> >>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] why so many processes are running at startup time?

[Sven Van Caekenberghe]

Camillo,

Let's hope you found the problem, make sure to double check with the team over 
there.

I added 
https://pharo.fogbugz.com/f/cases/10998/Add-ReleaseTest-testUnknownProcesses 
but this might be hard to make work in practice.

Sven

On 23 Jun 2013, at 14:47, Camillo Bruni  wrote:

> I propose to enable again that on image startup the timer scheduling process 
> is restarted.
> 
> https://pharo.fogbugz.com/default.asp?10994
> https://pharo.fogbugz.com/default.asp?10545
> 
> I am not fully sure of the implications, but it used to be there before and I 
> have less troubles when it is enabled ;)
> 
> On 2013-06-20, at 10:02, Marcus Denker  wrote:
>> Hi,
>> 
>> I think we should for now just kill them when building the image, I will 
>> check.
>> 
>> On Jun 20, 2013, at 9:56 AM, Clément Bera  wrote:
>> 
>>> Hello,
>>> 
>>> These processes are due to the new integration testing process. This new 
>>> process was introduced in Pharo 3.0 alpha, and we found the bug and fixed 
>>> it. 
>>> Recently we backport the new integration process to Pharo 2.0 and seemingly 
>>> it created the same bug but since we read your mail we were not aware of 
>>> it. We need to backport the fix.
>>> We will fix that within a few days.
>>> 
>>> As a workaround, you can just kill these processes in your image for now ...
>>> 
>>> Thanks for reporting the issue,
>>> 
>>> 
>>> 
>>> 
>>> 2013/6/20 NISHIHARA Satoshi 
>>> There are 30 over processes are running at startup, Pharo-20607.image.
>>> 
>>> 
>>> 
>>> regards.
>>> 
>>> -- 
>>> --
>>> "NISHIHARA Satoshi"
>>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
>>> 
>>> 
>>> 
>>> -- 
>>> Clément Béra
>>> Mate Virtual Machine Engineer
>>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> 
> 
> 

Re: [Pharo-dev] Object >> #is:

[Camillo Bruni]

On 2013-06-23, at 19:19, Nicolas Cellier  
wrote:

> Except that if an object both is: this and is: that, from two different
> packages, this will lead to an override.

from which package? #is: doesn't seem to be used in general

> 2013/6/23 Sven Van Caekenberghe 
> 
>> 
>> On 23 Jun 2013, at 18:14, Camillo Bruni  wrote:
>> 
>>> can we remove that, or is this still in use?
>> 
>> Hmm, no senders, no implementors, but the idea is not bad: it could
>> replace a lot of methods. And it bears the signature of some illustrious
>> hackers…
>> 
>> Sven
>> 

Re: [Pharo-dev] First shot on acceptance tests for the VM

[Tudor Girba]

+1

Doru


On Sat, Jun 22, 2013 at 9:28 AM, Marcus Denker wrote:

> Very nice!
>
> Another thing we need to look at at some point is to make different VM
> build for each major version.
>
> The idea is that there is a dedicated build of the VM for "Pharo3", which
> would be frozen with the release,
> and then we start with a VM build for "Pharo4".
>
> I even want them to have the major version number is the binary, so that
> it is easy to install "Pharo3" in Parallel
> to "Pharo4".
>
> With this we free ourselves from needed the VM to be at  the same time
> forward *and* backward compatible.
> And we make sure that the VM that people use for the stable release does
> not change.
>
> Marcus
>
> On Jun 21, 2013, at 5:08 PM, Guillermo Polito 
> wrote:
>
> Hi!
>
> We were discussing over here about it, so I decided to finally start
> something on the front of an acceptance test for our VM.
>
> The core idea is to stress the VM to test its stability and find bugs and
> regressions.
>
> So I created the ci job in [1] which does:
>  - use latest vm
>  - use 2.0 latest image
>  - loads seaside and moose on it
>  - runs all tests
>
> Right now it runs on 6 different slaves, getting different results on
> each, which we should take care about :).
>
> Also there are some things on it that should be improved easily:
>  - once 2.0 summer is released this job should use that version instead of
> the "latest" 2.0
>  - right now we are loading the development version of moose because moose
> 4.8 is not released (but will be soon :)
>
> And of course, now we have them, we can improve them (and make them run
> because not all of them do :D).
>
> Guille
>
> [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] First shot on acceptance tests for the VM

[Tudor Girba]

Excellent!

Doru


On Fri, Jun 21, 2013 at 5:08 PM, Guillermo Polito  wrote:

> Hi!
>
> We were discussing over here about it, so I decided to finally start
> something on the front of an acceptance test for our VM.
>
> The core idea is to stress the VM to test its stability and find bugs and
> regressions.
>
> So I created the ci job in [1] which does:
>  - use latest vm
>  - use 2.0 latest image
>  - loads seaside and moose on it
>  - runs all tests
>
> Right now it runs on 6 different slaves, getting different results on
> each, which we should take care about :).
>
> Also there are some things on it that should be improved easily:
>  - once 2.0 summer is released this job should use that version instead of
> the "latest" 2.0
>  - right now we are loading the development version of moose because moose
> 4.8 is not released (but will be soon :)
>
> And of course, now we have them, we can improve them (and make them run
> because not all of them do :D).
>
> Guille
>
> [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] StartupPreference bug?

[Stéphane Ducasse]

apparently with the latest image it works

StartupLoader default executeAtomicItems: {
StartupAction name: 'Basic settings' code: [ ^MAuthor fullName: 
'MarianoMartinezPeck'.^MDebugger alwaysOpenFullDebugger: true ].
}.


so this was probably a problem with the block printing code.

Stef

On Jun 23, 2013, at 7:30 PM, Stéphane Ducasse  wrote:

> | items |
> items := OrderedCollection new.
> items add: (StartupAction
>  name: 'Basic settings'
>  code: [
>  Author fullName: 'MarianoMartinezPeck'.
>  Debugger alwaysOpenFullDebugger: true.]).
> StartupLoader default 
>addAtStartupInPreferenceVersionFolder: items 
>named: 'basicSettings.st'.
> 
> generates
> 
> more basicSettings.st 
> StartupLoader default executeAtomicItems: {
>StartupAction name: 'Basic settings' code: [...].
> }.
> 
> 
> Stef
> 

Re: [Pharo-dev] First shot on acceptance tests for the VM

[Guillermo Polito]

On Sat, Jun 22, 2013 at 9:28 AM, Marcus Denker wrote:

> Very nice!
>
> Another thing we need to look at at some point is to make different VM
> build for each major version.
>

Then we have to branch vm sources on release :)


>
> The idea is that there is a dedicated build of the VM for "Pharo3", which
> would be frozen with the release,
> and then we start with a VM build for "Pharo4".
>
> I even want them to have the major version number is the binary, so that
> it is easy to install "Pharo3" in Parallel
> to "Pharo4".
>
> With this we free ourselves from needed the VM to be at  the same time
> forward *and* backward compatible.
> And we make sure that the VM that people use for the stable release does
> not change.
>
> Marcus
>
> On Jun 21, 2013, at 5:08 PM, Guillermo Polito 
> wrote:
>
> Hi!
>
> We were discussing over here about it, so I decided to finally start
> something on the front of an acceptance test for our VM.
>
> The core idea is to stress the VM to test its stability and find bugs and
> regressions.
>
> So I created the ci job in [1] which does:
>  - use latest vm
>  - use 2.0 latest image
>  - loads seaside and moose on it
>  - runs all tests
>
> Right now it runs on 6 different slaves, getting different results on
> each, which we should take care about :).
>
> Also there are some things on it that should be improved easily:
>  - once 2.0 summer is released this job should use that version instead of
> the "latest" 2.0
>  - right now we are loading the development version of moose because moose
> 4.8 is not released (but will be soon :)
>
> And of course, now we have them, we can improve them (and make them run
> because not all of them do :D).
>
> Guille
>
> [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/
>
>
>

[Pharo-dev] StartupPreference bug?

[Stéphane Ducasse]

| items |
items := OrderedCollection new.
items add: (StartupAction
  name: 'Basic settings'
  code: [
  Author fullName: 'MarianoMartinezPeck'.
  Debugger alwaysOpenFullDebugger: true.]).
StartupLoader default 
addAtStartupInPreferenceVersionFolder: items 
named: 'basicSettings.st'.

generates

more basicSettings.st 
StartupLoader default executeAtomicItems: {
StartupAction name: 'Basic settings' code: [...].
}.


Stef

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

[kilon]

thank you , it works now. 



--
View this message in context: 
http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694696.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Object >> #is:

[Nicolas Cellier]

Except that if an object both is: this and is: that, from two different
packages, this will lead to an override.


2013/6/23 Sven Van Caekenberghe 

>
> On 23 Jun 2013, at 18:14, Camillo Bruni  wrote:
>
> > can we remove that, or is this still in use?
>
> Hmm, no senders, no implementors, but the idea is not bad: it could
> replace a lot of methods. And it bears the signature of some illustrious
> hackers…
>
> Sven
>

Re: [Pharo-dev] Object >> #is:

[Sven Van Caekenberghe]

On 23 Jun 2013, at 18:14, Camillo Bruni  wrote:

> can we remove that, or is this still in use?

Hmm, no senders, no implementors, but the idea is not bad: it could replace a 
lot of methods. And it bears the signature of some illustrious hackers…

Sven

[Pharo-dev] Object >> #is:

[Camillo Bruni]

can we remove that, or is this still in use?

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

[Marcus Denker]

On Jun 23, 2013, at 5:51 PM, kilon  wrote:

> yeah and I read about that in PBE and of course I forgot about it. That is
> why we need the mailing lists. 
> 
> Ok that solved the problem partially it does not complain about
> strVertexShader but it still complains about strFragmentShader . I use this
> code.
> 
> shaderList := {strVertexShader strFragmentShader}. 
> 
> Any idea what may still be wrong ? 
> 

There needs to be a dot:

shaderList := {strVertexShader . strFragmentShader}. 

(I guess I forgot to put it in my example)

> "strFragmentShader appears to be unused in this method. Ok to remove it ?"

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

[kilon]

yeah and I read about that in PBE and of course I forgot about it. That is
why we need the mailing lists. 

Ok that solved the problem partially it does not complain about
strVertexShader but it still complains about strFragmentShader . I use this
code.

 shaderList := {strVertexShader strFragmentShader}. 

Any idea what may still be wrong ? 

"strFragmentShader appears to be unused in this method. Ok to remove it ?"



--
View this message in context: 
http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694685.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] [update 3.0] #30216

[Marcus Denker]

30216
-

10995 remove #printWithClosureAnalysisOn:
https://pharo.fogbugz.com/f/cases/10995

10985 StepList full of useless morphs
https://pharo.fogbugz.com/f/cases/10985

10892 flatCollect added to pharo
https://pharo.fogbugz.com/f/cases/10892

Diff information:
http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.516.diff
http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.17.diff
http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1493.diff
http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.491.diff
http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Abstract-MarcusDenker.210.diff

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

[Marcus Denker]

On Jun 23, 2013, at 4:52 PM, kilon  wrote:

> next question .
> 
> I have this method.
> 
> initializeProgram
>   "create each shader and program"
> 
>   | shaderList strVertexShader strFragmentShader |
>   
>   strVertexShader  := self createShader: GL_VERTEX_SHADER string:  ( self
> vertexShader ).
>   strFragmentShader  := self createShader:  GL_FRAGMENT_SHADER string: 
> (self
> fragmentShader) .  
>   shaderList := #( strVertexShader strFragmentShader ).
>   self createProgram:  shaderList .
>   shaderList do: [ :each | gl deleteShader: each  ].
> 
> 
> Each time I try to accept the code it complains that strVertexShader and
> strFragmentShader are unused and ask for removing them . Why ?
> 
> Is this an IDE bug ? Its clear from the code that I use those two local
> variables to pass them to the array shaderList. Am I missing something here
> ? 

Yes:

shaderList := #( strVertexShader strFragmentShader ).

here the Array you create is a so called literal Array. It can not contain 
variables, only literals. The compiler sees is as

#(#strVertexShader #strFragmentShader).

What you need instead is a compile time evaluated Array:

shaderList := {strVertexShader strFragmentShader}.

Marcus
 

Re: [Pharo-dev] [update 3.0] #30215

[Stéphane Ducasse]

+1 

On Jun 23, 2013, at 12:31 PM, Camillo Bruni  wrote:

> 
> On 2013-06-23, at 12:29, Damien Cassou  wrote:
> 
>> On Fri, Jun 21, 2013 at 6:16 PM, Esteban Lorenzano  
>> wrote:
>>> (pass 6, last?)
>> 
>> 
>> looks like it was the last one. I would like to congratulate and thank
>> Sebastian and you. This change was not easy at all and the results are
>> important. For example, now, the RGClass class, the Trait class and
>> the Class class will be truly polymorphic.
> 
> 
> good job guys! this one was bugging me for a while, but I never had the 
> courage
> to deal with it ;)

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

[kilon]

next question .

I have this method.

initializeProgram
"create each shader and program"

| shaderList strVertexShader strFragmentShader |

strVertexShader  := self createShader: GL_VERTEX_SHADER string:  ( self
vertexShader ).
strFragmentShader  := self createShader:  GL_FRAGMENT_SHADER string: 
(self
fragmentShader) .  
shaderList := #( strVertexShader strFragmentShader ).
self createProgram:  shaderList .
shaderList do: [ :each | gl deleteShader: each  ].


Each time I try to accept the code it complains that strVertexShader and
strFragmentShader are unused and ask for removing them . Why ?

Is this an IDE bug ? Its clear from the code that I use those two local
variables to pass them to the array shaderList. Am I missing something here
? 




--
View this message in context: 
http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694650.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

[kilon]

No I did not, because I dont have the brain power to assume that
NBExternalAdress will have some methods to make my life easier. And of
course it works like a charm now, thank you very much :) 



--
View this message in context: 
http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694639.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] why so many processes are running at startup time?

[Camillo Bruni]

I propose to enable again that on image startup the timer scheduling process is 
restarted.

https://pharo.fogbugz.com/default.asp?10994
https://pharo.fogbugz.com/default.asp?10545

I am not fully sure of the implications, but it used to be there before and I 
have less troubles when it is enabled ;)

On 2013-06-20, at 10:02, Marcus Denker  wrote:
> Hi,
> 
> I think we should for now just kill them when building the image, I will 
> check.
> 
> On Jun 20, 2013, at 9:56 AM, Clément Bera  wrote:
> 
>> Hello,
>> 
>> These processes are due to the new integration testing process. This new 
>> process was introduced in Pharo 3.0 alpha, and we found the bug and fixed 
>> it. 
>> Recently we backport the new integration process to Pharo 2.0 and seemingly 
>> it created the same bug but since we read your mail we were not aware of it. 
>> We need to backport the fix.
>> We will fix that within a few days.
>> 
>> As a workaround, you can just kill these processes in your image for now ...
>> 
>> Thanks for reporting the issue,
>> 
>> 
>> 
>> 
>> 2013/6/20 NISHIHARA Satoshi 
>> There are 30 over processes are running at startup, Pharo-20607.image.
>> 
>> 
>> 
>> regards.
>> 
>> -- 
>> --
>> "NISHIHARA Satoshi"
>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
>> 
>> 
>> 
>> -- 
>> Clément Béra
>> Mate Virtual Machine Engineer
>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
> 

Re: [Pharo-dev] [update 3.0] #30215

[Sebastian Tleye]

Thanks :-)
There are still some details to fix before continue with Trait and RGClass
but quite easy


2013/6/23 Camillo Bruni 

>
> On 2013-06-23, at 12:29, Damien Cassou  wrote:
>
> > On Fri, Jun 21, 2013 at 6:16 PM, Esteban Lorenzano 
> wrote:
> >> (pass 6, last?)
> >
> >
> > looks like it was the last one. I would like to congratulate and thank
> > Sebastian and you. This change was not easy at all and the results are
> > important. For example, now, the RGClass class, the Trait class and
> > the Class class will be truly polymorphic.
>
>
> good job guys! this one was bugging me for a while, but I never had the
> courage
> to deal with it ;)
>

Re: [Pharo-dev] [update 3.0] #30215

[Camillo Bruni]

On 2013-06-23, at 12:29, Damien Cassou  wrote:

> On Fri, Jun 21, 2013 at 6:16 PM, Esteban Lorenzano  
> wrote:
>> (pass 6, last?)
> 
> 
> looks like it was the last one. I would like to congratulate and thank
> Sebastian and you. This change was not easy at all and the results are
> important. For example, now, the RGClass class, the Trait class and
> the Class class will be truly polymorphic.


good job guys! this one was bugging me for a while, but I never had the courage
to deal with it ;)

Re: [Pharo-dev] [update 3.0] #30215

[Damien Cassou]

On Fri, Jun 21, 2013 at 6:16 PM, Esteban Lorenzano  wrote:
> (pass 6, last?)


looks like it was the last one. I would like to congratulate and thank
Sebastian and you. This change was not easy at all and the results are
important. For example, now, the RGClass class, the Trait class and
the Class class will be truly polymorphic.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

[Guy Hylton]

Have you tried

(gl getString: GL_VERSION) readString

or if it does not return an NBExternalAddress

(NBExternalAddress value: (gl getString: GL_VERSION)) readstring




On Sat, Jun 22, 2013 at 4:46 PM, kilon  wrote:

> I am trying to find out what version of Opengl NBOpenGL is using so I do:
>
> gl getString:GL_VERSION.
>
> it works and returns me a pointer. I looked at definition of methods and it
> is defined to return a pointer.
>
> Question is how I get the string that the pointer points too ?
>
>
>
> --
> View this message in context:
> http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694552.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Startup preferences

[Damien Cassou]

StatupLoader>>preferencesGeneralFolder

^ FileLocator preferences asFileReference / 'pharo'.

On Sat, Jun 22, 2013 at 10:33 AM, p...@highoctane.be  wrote:
> Pretty cool script.
>
> I like the colors thing :-)
>
> Phil
>
> ---
> Philippe Back
> Dramatic Performance Improvements
> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
> Mail:p...@highoctane.be | Web: http://philippeback.eu
> Blog: http://philippeback.be | Twitter: @philippeback
> Youtube: http://www.youtube.com/user/philippeback/videos
>
> High Octane SPRL
> rue cour Boisacq 101 | 1301 Bierges | Belgium
>
> Featured on the Software Process and Measurement Cast
> http://spamcast.libsyn.com
> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value
> Added Reseller
>
>
>
>
> On Sat, Jun 22, 2013 at 1:00 AM, Clément Bera 
> wrote:
>>
>> It should be.
>>
>> You have to put the script in "~/Library/Preferences/pharo/ "
>>
>> You can check the startup script of Camillo in its github repository
>> (https://github.com/dh83/script/blob/master/pharo-preferences.st).
>>
>>
>> 2013/6/21 Stéphane Ducasse 
>>>
>>> Hi guys
>>>
>>> I want to write something on the preferences loading at startup.
>>> Now do you know if
>>>
>>> http://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-scripts-in-pharo/
>>> is more or less up to date?
>>>
>>> Stef
>>
>>
>>
>>
>> --
>> Clément Béra
>> Mate Virtual Machine Engineer
>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>



-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Re: [Pharo-dev] Smalltalkhub url

[Camillo Bruni]

On 2013-06-23, at 00:50, Alexandre Bergel  wrote:

> Hi!
> 
> Just wondering whether urls do need to have #! and ~ in the url?
> E.g., http://smalltalkhub.com/#!/~ainfante/MemoryProfiler


Could be possible
1) replace ~ with a subdirectory /users/ or so (though I don't see any 
advantage of this)
2) replace the fragment-based navigation with something that uses 
history.pushState

1) could be done with relative little overhead, 2) is going to be more work.