date:20100419


On Apr 19, 2010, at 1:56 AM, Stephen Taylor wrote:

 Henrik Johansen wrote:
 
 Gotta love reddit...
 [...]
 - I don't know what Smalltalk is, and the site doesn't tell me, not even 
 the about page!
 
 That one I think is legitimate - and not just for Pharo but for almost every 
 Open Source project out there. I think every project's home page should keep 
 first time in visitors in mind. (My very least favourite thing for the first 
 page of a site is to see the project commit log - talk about unwelcoming!).

Good remark.
Thanks.
Does anybody have some text we could reuse?

 And to say something positive - Pharo 1.0 looks great - solid and serious and 
 workable. A couple of my co-workers have called my bluff and asked for a 
 Smalltalk tutorial, and I'll be happy to show them Pharo.

Excellent.  :)

Now I hope that in the future we will be able to amazed smalltalkers 
themselves... because this is the key point. If we succeed to have so a cool (I 
mean really cool)
system then we will have done a good job 

Stef



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] we need help for rome

probably :)
one coming from sophie and one coming from the repository.
We will fix that as soon as we can make it run on mac (ok we just have to add 
the inst var) but would be nice to have a clean
plugin but I imagine that john is stressed with the Scratch problem.

Stef

On Apr 19, 2010, at 8:44 AM, Alain Plantec wrote:

 Stéphane Ducasse a écrit :
 Thanks john oops I learned something.
 Now the problem is that I did not touch them. I just loaded code. So I 
 wonder where they got lost or changed.
 
 Alain do you have the same in your image?
  
 Hi all,
 Just back from a cool week-end, with a lot of sun...
 Yes, my RomePluginCanvas is the same as yours and it runs well on linux.
 But I've not removed any inst var myself.
 My version comes from the www.squeaksource.com/Rome.
 I've checked, and the RomePluginCanvas from squeaksource is still the same as 
 mine:
 
 RomeCanvas subclass: #RomePluginCanvas
   instanceVariableNames: 'handle target flags strokeColor stack font fontSize 
 fontMatrix'
   classVariableNames: 'FlagFill FlagStroke Registry'
   poolDictionaries: ''
   category: 'Rome-PluginCanvas'
 
 so, does it means that there are also two version of the plugin ?
 
 Cheers
 Alain
 Stef
 
 On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote:
 
  
 (a) In Sophie   RomeCanvas subclass: #RomePluginCanvas
 instanceVariableNames: 'handle target flags strokeColor stack font 
 fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy 
 cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY'
 classVariableNames: 'CachedTarget FlagFill FlagStro
 
 (b) In Pharo 
 RomeCanvas subclass: #RomePluginCanvas
 instanceVariableNames: 'handle target flags strokeColor stack font 
 fontSize fontMatrix'
 classVariableNames: 'FlagFill FlagStroke Registry'
 poolDictionaries: ''
 category: 'Rome-PluginCanvas'
 
 Comment warning: 
 INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE!
 
 
 So in the plugin we have... 
 if (interpreterProxy-slotSizeOf(canvasOop))  CanvasInstSize)
 fail().
 
 
 where CanvasInstSize is 13
 
 but as you see in (b) the number of instance slots for the canvas Oops is  
 8. 
 8  13, oops you fail. 
 So where did the instance vars   currentFillColor currentBackColor 
 glyphAccuracy cachedGlyphBlt cachedClearBlt
 go? On purpose gone, refactored, old code. etc 
 
 On 2010-04-16, at 1:37 PM, Stéphane Ducasse wrote:
 

 On Apr 16, 2010, at 10:30 PM, John McIntosh wrote:
 
  
 Well I'm just as puzzled as you since the primitive gets executed and you 
 are using the same binary that was shipped with Sophie years back.
  
 I like to hear that because I feel less idiot. :)
 
 
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
  
 --
 ===
 John M. McIntosh john...@smalltalkconsulting.com   Twitter:  squeaker68882
 Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
 ===
 
 
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
  
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Help on collaborator Active book

On Sunday, April 18, 2010, Tudor Girba tudor.gi...@gmail.com wrote:
 Fixed.

 Doru

thanks!
Mike

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Help on collaborator Active book


On Apr 19, 2010, at 8:45 AM, laurent laffont wrote:

 
 List of Plugins @
 http://book.pharo-project.org/book/Virtual-Machine/VMPlugins/VMPluginsList
 * GeniePlugin : This plugin implements the functionality of ???
 * SurfacePlugin : This plugin is a fake uh, what, lol
 
 
 Thanks for your help Sean. 
 
 For list of Plugins I've just extracted  the first sentence of each Plugin's 
 comment for start to be continued :)
 
 I would like to add for each plugin whether it's safe to built it internal or 
 external.
 
 A section on how to write its own plugin would be cool.


there is a chapter in the new blue book on my free books web page that explains 
that.
We could get inspired. 

 And how to interface to an existing library. (QT, GTK, Webkit, ...) too.
 
 Can someone write the Mac OSX / Windows way to build the VM ? 

Yes jean-baptiste has that on his todo.

 
 Cheers,
 
 Laurent Laffont
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Issue tracking system

2010-04-19 Thread Göran Krampe


Hi!

laurent laffont wrote:

OK Thanks.

Laurent Laffont


On Fri, Apr 16, 2010 at 9:37 PM, Torsten Bergmann asta...@gmx.de 
mailto:asta...@gmx.de wrote:


Sorry ... have to correct myself: Gjallar is based on Seaside.


Indeed it is and AFAIK it should probably work fine in Pharo too. 
Gjallar has been semi sleeping for a while but I intend to try to move 
it forward and we have a customer pushing me also :)


Please send any questions to the Gjallar mailinglist or to me privately 
and I will answer.


regards, Göran

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Canvas transform bug when rendering text?

2010-04-19 Thread Adrian Lienhard

Yes, please tag important fixes with milestone 1.0.1. I added this milestone as 
a predefined label (so it will show up in the autocompleter).

Adrian

On Apr 18, 2010, at 13:12 , Stéphane Ducasse wrote:

 
 On Apr 18, 2010, at 10:32 AM, Michael Roberts wrote:
 
 On Sun, Apr 18, 2010 at 8:21 AM, Stéphane Ducasse
 stephane.duca...@inria.fr wrote:
 we should release 1.1 much faster :)
 like that people will be able to get all the fixes
 
 yes ;)
 
 for tagging fixes for 1.0 maintenance, should we use a milestone 1.0.1
 in the tracker?   - is this code candidate for 1.0.1?
 
 1.0.1 would be better because we really want to not spend too much time on 
 this one 
 since far too many fixes were made in 1.1
 
 Stef
 
 
 cheers,
 Mike
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Iliad 0.8 released!

2010-04-19 Thread Julian Fitzell

2010/4/18 Nicolas Petton petton.nico...@gmail.com

 Le dimanche 18 avril 2010 à 19:25 +0100, Julian Fitzell a écrit :
  2010/4/18 Nicolas Petton petton.nico...@gmail.com
  Now I'm not really happy with the codec stuff, as from a GNU
  Smalltalker
  point of view it seems too Squeak/Pharo oriented, but I can
  leave with
  that for now.
 
  To be honest, I'm not totally happy with that part either. :) It's
  good enough for now but reworking the encoding stuff is on my
  (personal, anyway) list for Seaside 3.1.

 Why do you keep Grease into Seaside's repository? Couldn't it have its
 own repository and roadmap?


I suppose it might have it's own repository sometime. It probably will have
its own roadmap. It will *definitely* have its own version numbering
(though releases will probably coincide fairly closely with Seaside's
releases, at least for a while - I'm imagining a 1.0 release to coincide
with Seaside's 3.0 final).

For now it's more convenient for us to have it all in one repository. Also,
we're not ready to cut the tie to Seaside... Grease is still, fundamentally,
Seaside's compatibility layer. For now we're doing what we can to keep it
general and inviting others to use it if it fits their needs (we certainly
hope it does), but we need to ensure it's fitting our needs. Over time, as
it becomes more general, if people are adopting it and we're more confident
in its evolution, maybe we'll cut it loose.

Julian
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Issue tracking system

2010-04-19 Thread laurent laffont

2010/4/19 Göran Krampe go...@krampe.se

 Hi!

 laurent laffont wrote:

 OK Thanks.

 Laurent Laffont



 On Fri, Apr 16, 2010 at 9:37 PM, Torsten Bergmann asta...@gmx.demailto:
 asta...@gmx.de wrote:

Sorry ... have to correct myself: Gjallar is based on Seaside.


 Indeed it is and AFAIK it should probably work fine in Pharo too. Gjallar
 has been semi sleeping for a while but I intend to try to move it forward
 and we have a customer pushing me also :)

 Please send any questions to the Gjallar mailinglist or to me privately and
 I will answer.

 regards, Göran


Hi,

I've just spent half an hour on it, unable to test the image provided on the
website, magma errors :( . I'll put this on Gjallar mailing list as soon as
I can.

Load it into Pharo, I want it !   ConfigurationOfGjallar would be cool.

Some questions, I haven't found answers on Gjallar website. One feature I
would like is to split and merge issues, and keep trac of this split /
merge.

For example, two customers can report the same bug. But they don't know each
other. I would like to create a merge of these two issues for me. When I
mark it as resolved, both customers can see automatically their issues as
resolved.

Sometimes a reported issue involves several tasks. I want to create these
tasks or split the issue in several sub-issues. When all sub-issues
resolved, the original one is marked as resolved.

Is it possible ?

Cheers,

Laurent Laffont




 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

2010-04-19 Thread Adrian Lienhard

On Apr 19, 2010, at 09:10 , Stéphane Ducasse wrote:

 On Apr 19, 2010, at 1:56 AM, Stephen Taylor wrote:
 
 Henrik Johansen wrote:
 
 Gotta love reddit...
 [...]
 - I don't know what Smalltalk is, and the site doesn't tell me, not even 
 the about page!
 
 That one I think is legitimate - and not just for Pharo but for almost every 
 Open Source project out there. I think every project's home page should keep 
 first time in visitors in mind. (My very least favourite thing for the first 
 page of a site is to see the project commit log - talk about unwelcoming!).
 
 Good remark.
 Thanks.
 Does anybody have some text we could reuse?

I think that anybody that is enough interested will be able to type Smalltalk 
into Google. Next, people are going to ask what a programming language is, and 
we have to explain that too ;)

Anyway, couldn't we just link the first occurrence of Smalltalk to 
en.wikipedia.org/wiki/Smalltalk?

 And to say something positive - Pharo 1.0 looks great - solid and serious 
 and workable. A couple of my co-workers have called my bluff and asked for a 
 Smalltalk tutorial, and I'll be happy to show them Pharo.

Thanks :)

Cheers,
Adrian
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Issue tracking system


On Apr 19, 2010, at 9:32 AM, Göran Krampe wrote:

 Hi!
 
 laurent laffont wrote:
 OK Thanks.
 Laurent Laffont
 On Fri, Apr 16, 2010 at 9:37 PM, Torsten Bergmann asta...@gmx.de 
 mailto:asta...@gmx.de wrote:
Sorry ... have to correct myself: Gjallar is based on Seaside.
 
 Indeed it is and AFAIK it should probably work fine in Pharo too. Gjallar has 
 been semi sleeping for a while but I intend to try to move it forward and 
 we have a customer pushing me also :)

This is a great news.

 
 Please send any questions to the Gjallar mailinglist or to me privately and I 
 will answer.
 
 regards, Göran
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

yes sounds good

Stef
 
 Anyway, couldn't we just link the first occurrence of Smalltalk to 
 en.wikipedia.org/wiki/Smalltalk?

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] we need help for rome

2010-04-19 Thread Cyrille Delaunay

Ok, it works when adding the instance variables:)
Thank you

2010/4/19 Stéphane Ducasse stephane.duca...@inria.fr

 probably :)
 one coming from sophie and one coming from the repository.
 We will fix that as soon as we can make it run on mac (ok we just have to
 add the inst var) but would be nice to have a clean
 plugin but I imagine that john is stressed with the Scratch problem.

 Stef

 On Apr 19, 2010, at 8:44 AM, Alain Plantec wrote:

  Stéphane Ducasse a écrit :
  Thanks john oops I learned something.
  Now the problem is that I did not touch them. I just loaded code. So I
 wonder where they got lost or changed.
 
  Alain do you have the same in your image?
 
  Hi all,
  Just back from a cool week-end, with a lot of sun...
  Yes, my RomePluginCanvas is the same as yours and it runs well on linux.
  But I've not removed any inst var myself.
  My version comes from the www.squeaksource.com/Rome.
  I've checked, and the RomePluginCanvas from squeaksource is still the
 same as mine:
 
  RomeCanvas subclass: #RomePluginCanvas
instanceVariableNames: 'handle target flags strokeColor stack font
 fontSize fontMatrix'
classVariableNames: 'FlagFill FlagStroke Registry'
poolDictionaries: ''
category: 'Rome-PluginCanvas'
 
  so, does it means that there are also two version of the plugin ?
 
  Cheers
  Alain
  Stef
 
  On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote:
 
 
  (a) In Sophie   RomeCanvas subclass: #RomePluginCanvas
  instanceVariableNames: 'handle target flags strokeColor stack font
 fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy
 cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY'
  classVariableNames: 'CachedTarget FlagFill FlagStro
 
  (b) In Pharo
  RomeCanvas subclass: #RomePluginCanvas
  instanceVariableNames: 'handle target flags strokeColor stack font
 fontSize fontMatrix'
  classVariableNames: 'FlagFill FlagStroke Registry'
  poolDictionaries: ''
  category: 'Rome-PluginCanvas'
 
  Comment warning:
  INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE!
 
 
  So in the plugin we have...
  if (interpreterProxy-slotSizeOf(canvasOop))  CanvasInstSize)
  fail().
 
 
  where CanvasInstSize is 13
 
  but as you see in (b) the number of instance slots for the canvas Oops
 is  8.
  8  13, oops you fail.
  So where did the instance vars   currentFillColor currentBackColor
 glyphAccuracy cachedGlyphBlt cachedClearBlt
  go? On purpose gone, refactored, old code. etc
 
  On 2010-04-16, at 1:37 PM, Stéphane Ducasse wrote:
 
 
  On Apr 16, 2010, at 10:30 PM, John McIntosh wrote:
 
 
  Well I'm just as puzzled as you since the primitive gets executed and
 you are using the same binary that was shipped with Sophie years back.
  I like to hear that because I feel less idiot. :)
 
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
  --
 
 ===
  John M. McIntosh john...@smalltalkconsulting.com   Twitter:
  squeaker68882
  Corporate Smalltalk Consulting Ltd.
 http://www.smalltalkconsulting.com
 
 ===
 
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] we need help for rome

good!

Stef

On Apr 19, 2010, at 10:28 AM, Cyrille Delaunay wrote:

 Ok, it works when adding the instance variables:)
 Thank you
 
 2010/4/19 Stéphane Ducasse stephane.duca...@inria.fr
 probably :)
 one coming from sophie and one coming from the repository.
 We will fix that as soon as we can make it run on mac (ok we just have to add 
 the inst var) but would be nice to have a clean
 plugin but I imagine that john is stressed with the Scratch problem.
 
 Stef
 
 On Apr 19, 2010, at 8:44 AM, Alain Plantec wrote:
 
  Stéphane Ducasse a écrit :
  Thanks john oops I learned something.
  Now the problem is that I did not touch them. I just loaded code. So I 
  wonder where they got lost or changed.
 
  Alain do you have the same in your image?
 
  Hi all,
  Just back from a cool week-end, with a lot of sun...
  Yes, my RomePluginCanvas is the same as yours and it runs well on linux.
  But I've not removed any inst var myself.
  My version comes from the www.squeaksource.com/Rome.
  I've checked, and the RomePluginCanvas from squeaksource is still the same 
  as mine:
 
  RomeCanvas subclass: #RomePluginCanvas
instanceVariableNames: 'handle target flags strokeColor stack font 
  fontSize fontMatrix'
classVariableNames: 'FlagFill FlagStroke Registry'
poolDictionaries: ''
category: 'Rome-PluginCanvas'
 
  so, does it means that there are also two version of the plugin ?
 
  Cheers
  Alain
  Stef
 
  On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote:
 
 
  (a) In Sophie   RomeCanvas subclass: #RomePluginCanvas
  instanceVariableNames: 'handle target flags strokeColor stack font 
  fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy 
  cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY'
  classVariableNames: 'CachedTarget FlagFill FlagStro
 
  (b) In Pharo
  RomeCanvas subclass: #RomePluginCanvas
  instanceVariableNames: 'handle target flags strokeColor stack font 
  fontSize fontMatrix'
  classVariableNames: 'FlagFill FlagStroke Registry'
  poolDictionaries: ''
  category: 'Rome-PluginCanvas'
 
  Comment warning:
  INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE!
 
 
  So in the plugin we have...
  if (interpreterProxy-slotSizeOf(canvasOop))  CanvasInstSize)
  fail().
 
 
  where CanvasInstSize is 13
 
  but as you see in (b) the number of instance slots for the canvas Oops is 
   8.
  8  13, oops you fail.
  So where did the instance vars   currentFillColor currentBackColor 
  glyphAccuracy cachedGlyphBlt cachedClearBlt
  go? On purpose gone, refactored, old code. etc
 
  On 2010-04-16, at 1:37 PM, Stéphane Ducasse wrote:
 
 
  On Apr 16, 2010, at 10:30 PM, John McIntosh wrote:
 
 
  Well I'm just as puzzled as you since the primitive gets executed and 
  you are using the same binary that was shipped with Sophie years back.
  I like to hear that because I feel less idiot. :)
 
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
  --
  ===
  John M. McIntosh john...@smalltalkconsulting.com   Twitter:  
  squeaker68882
  Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
  ===
 
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Vm-dev] Re: we need help for rome


On Apr 18, 2010, at 11:57 PM, Bert Freudenberg wrote:

 On 18.04.2010, at 20:14, stephane ducasse wrote:
 
 
 Thanks Bert
 
 
 I think only the first 4 inst vars are actually used by the plugin:
 
 http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/RomePlugin.c
 #define CanvasHandleIndex 0
 #define CanvasTargetIndex 1
 #define CanvasFlagsIndex 2
 #define CanvasStrokeColorIndex 3
 #define CanvasInstSize 8
 
 how did you get that information? from the image side or C code?
 Because I tried to see but unsure.
 
 It's in the C code I linked above. I just reordered it for better readability.

Yes I saw my question was more how do we identify code that is not used anymore?
We just do the closure over the published primitives and the rest means that it 
is useful.
My question was how did you identify that only 4 inst were used and not more. 

 The proper fix would be to modify RomePlugin 
 classinitializeInstVarIndices to not generate the indices, but simply 
 hard-code only the used ones (setting CanvasInstSize to 4), and change the 
 comparison John mentioned below to =. Also remove the unused *Index class 
 vars. Now that there are plugins in the wild, hard-coding the indices is a 
 good idea anyway. During development, the flexible generator version was 
 useful, but not anymore.


Ok I will browse the RomePlugin class with Cyrille and Jean-Baptiste


 I browsed a bit the C code and I'm learning so may be my questions are not 
 clever, but 
 
  - do we need the pango primitives for ROME?
  Apparently Pango may use Cairo for fonts rendering but do Rome needs 
 that?
  So is it simpler to use fonts via pango than cairo.
 
 Pango provides word/paragraph layout. Many non-latin scripts (e.g. 
 Devanagari) require glyph shaping, there is no one-to-one mapping between 
 Unicode characters and glyphs rendered in context. Pango can do that. I'm not 
 aware of any other renderer in Squeak that would support this (Yoshiki added 
 it for OLPC). Well, maybe the Unicode plugin from Scratch could do it too, 
 not sure.
 
  - then what about FormInstSize?
 
  (interpreterProxy-slotSizeOf(formOop))  FormInstSize
  does it mean
 
 Same thing. The instance variables actually used by the plugin should be hard 
 coded. Otherwise the same would happen as in Sophie - some inst vars were 
 added to the Canvas, so the inst size compiled into the plugin became larger 
 than necessary.
 
 Btw, by now you probably have guessed that a workaround for the Mac issue 
 would be to add 5 dummy inst vars to RomePluginCanvas just to make the plugin 
 happy.

Yes. In fact my question was more is FormInstSize used (or are the 
functionality using FormInstSize used)?

I have problems to see how we can clean the C code.
All my questions should be interpreted with this slant. 

 It doesn't need to be in sync. But maybe I do not understand the question.

Sorry was not clear.
My question is how Cairo supports backwards compatibility?
What happens if the plugin expect a different version of Cairo on the machine?
May be they do not change their interface?

Stef



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] we need help for rome

Ok I will ask cyrille if he can have a look at the c :)

Stef

On Apr 18, 2010, at 11:23 PM, John M McIntosh wrote:

 Well hey I'm just the guy tapping the compile button, er no support agreement 
 here... 
 
 Likely the original plugin code came via 
 
 MCHttpRepository
   location: 'http://source.impara.de/Rome'
   user: ''
   password: ''

This is strange because I think that alain took it from there too.
May be not.

Stef


 
 If someone wants to make the required fixes to the plugin code, and the 
 smalltalk code I *think* I can build a new plugin..  Likely this won't affect 
 Sophie users (if any) because that's a one click app. However this means an 
 update to the mac vm's and other platforms in order to ensure the smalltalk 
 class in a Pharo image matches expectations. 
 
 On 2010-04-18, at 10:45 AM, Bert Freudenberg wrote:
 
 
 I think only the first 4 inst vars are actually used by the plugin:
 
 http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/RomePlugin.c
 #define CanvasHandleIndex 0
 #define CanvasTargetIndex 1
 #define CanvasFlagsIndex 2
 #define CanvasStrokeColorIndex 3
 #define CanvasInstSize 8
 
 So on Linux, Rome does use the right size. John appears to have used a 
 Sophie image to generate his Plugin, which makes this fail (though I could 
 not find his Rome plugin in the Mac OS platform code so can't verify that 
 theory).
 
 The proper fix would be to modify RomePlugin classinitializeInstVarIndices 
 to not generate the indices, but simply hard-code only the used ones 
 (setting CanvasInstSize to 4), and change the comparison John mentioned 
 below to =. Also remove the unused *Index class vars. Now that there are 
 plugins in the wild, hard-coding the indices is a good idea anyway. During 
 development, the flexible generator version was useful, but not anymore.
 
 - Bert -
 
 
 --
 ===
 John M. McIntosh john...@smalltalkconsulting.com   Twitter:  squeaker68882
 Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
 ===
 
 
 
 






___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Help on collaborator Active book

thanks

 
 
 Fixing underscores @
 http://book.pharo-project.org/book/TipsAndTricks/FixingUnderscores
 * I wasn't sure whether this was an instruction, a suggestion, or merely an
 option.  Is this necessary? personal preference?  Again, some background
 would help.

I fixed that.


 
 Traits @ http://book.pharo-project.org/book/Traits:
 * This one I found very tough.  Especially the initial part of the
 BulletinBoard example.  I wasn't sure how I would play with the example in
 my own image.  For instance, what should the subclass of BulletinBoard be?
 
 * BoardListener new listenAndReact
 makes sure that each time the method announceNewAddedItem is executed on the
 created bulletinBoard, the event is received by the listener.  Does it?  It
 seems to just write to the Transcript, and not be connected to the listener
 at all.
 
 * Open an inspector on the expression above - which expression?
 
 * ! Going deeper
 When applying a trait to a class it may face different situations.
 
 * !!Using Alias to access a hidden method  This section (the beginning
 anyway), seemed to describe something different than the title here.
 
 It's great to have a resource like this - let's squeeze all the juice out of
 it.



I will fix the rest later.

 
 Sean
 -- 
 View this message in context: 
 http://n4.nabble.com/Help-on-collaborator-Active-book-tp2014707p2015363.html
 Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] we need help for rome

2010-04-19 Thread Alain Plantec

Stéphane Ducasse a écrit :

Ok I will ask cyrille if he can have a look at the c :)

Stef

On Apr 18, 2010, at 11:23 PM, John M McIntosh wrote:

Well hey I'm just the guy tapping the compile button, er no support agreement here...

Likely the original plugin code came via

MCHttpRepository
location: 'http://source.impara.de/Rome'
user: ''
password: ''

This is strange because I think that alain took it from there too.
May be not.

I took it from squeaksource, not from source.impara.de.
so two repositories.
why ?
does someone knows ?
Cheers
Alain

Stef

If someone wants to make the required fixes to the plugin code, and the smalltalk code I *think* I can build a new plugin.. Likely this won't affect Sophie users (if any) because that's a one click app. However this means an update to the mac vm's and other platforms in order to ensure the smalltalk class in a Pharo image matches expectations.

On 2010-04-18, at 10:45 AM, Bert Freudenberg wrote:

I think only the first 4 inst vars are actually used by the plugin:

http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/RomePlugin.c
#define CanvasHandleIndex 0
#define CanvasTargetIndex 1
#define CanvasFlagsIndex 2
#define CanvasStrokeColorIndex 3
#define CanvasInstSize 8

So on Linux, Rome does use the right size. John appears to have used a Sophie
image to generate his Plugin, which makes this fail (though I could not find his Rome
plugin in the Mac OS platform code so can't verify that theory).

The proper fix would be to modify RomePlugin classinitializeInstVarIndices to
not generate the indices, but simply hard-code only the used ones (setting
CanvasInstSize to 4), and change the comparison John mentioned below to =. Also
remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding
the indices is a good idea anyway. During development, the flexible generator version
was useful, but not anymore.

- Bert -

--
===
John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] we need help for rome

sophie used the impara ones.
So now this is good that we merged and check in the rome one. 
And probably repackage everything in Athens.

Stef
 
 
 Stéphane Ducasse a écrit :
 Ok I will ask cyrille if he can have a look at the c :)
 
 Stef
 
 On Apr 18, 2010, at 11:23 PM, John M McIntosh wrote:
 
  
 Well hey I'm just the guy tapping the compile button, er no support 
 agreement here... 
 Likely the original plugin code came via 
 MCHttpRepository
 location: 'http://source.impara.de/Rome'
 user: ''
 password: ''

 
 This is strange because I think that alain took it from there too.
 May be not.
  
 I took it from squeaksource, not from source.impara.de.
 so two repositories.
 why ?
 does someone knows ?
 Cheers
 Alain
 Stef
 
 
  
 If someone wants to make the required fixes to the plugin code, and the 
 smalltalk code I *think* I can build a new plugin..  Likely this won't 
 affect Sophie users (if any) because that's a one click app. However this 
 means an update to the mac vm's and other platforms in order to ensure the 
 smalltalk class in a Pharo image matches expectations. 
 On 2010-04-18, at 10:45 AM, Bert Freudenberg wrote:
 

 I think only the first 4 inst vars are actually used by the plugin:
 
 http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/RomePlugin.c
 #define CanvasHandleIndex 0
 #define CanvasTargetIndex 1
 #define CanvasFlagsIndex 2
 #define CanvasStrokeColorIndex 3
 #define CanvasInstSize 8
 
 So on Linux, Rome does use the right size. John appears to have used a 
 Sophie image to generate his Plugin, which makes this fail (though I could 
 not find his Rome plugin in the Mac OS platform code so can't verify that 
 theory).
 
 The proper fix would be to modify RomePlugin 
 classinitializeInstVarIndices to not generate the indices, but simply 
 hard-code only the used ones (setting CanvasInstSize to 4), and change the 
 comparison John mentioned below to =. Also remove the unused *Index class 
 vars. Now that there are plugins in the wild, hard-coding the indices is a 
 good idea anyway. During development, the flexible generator version was 
 useful, but not anymore.
 
 - Bert -
 
  
 --
 ===
 John M. McIntosh john...@smalltalkconsulting.com   Twitter:  squeaker68882
 Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
 ===
 
 
 
 

 
 
 
 
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
  
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Vm-dev] Re: we need help for rome

2010-04-19 Thread Bert Freudenberg

On 19.04.2010, at 10:42, Stéphane Ducasse wrote:
 
 
 On Apr 18, 2010, at 11:57 PM, Bert Freudenberg wrote:
 
 On 18.04.2010, at 20:14, stephane ducasse wrote:
 
 
 Thanks Bert
 
 
 I think only the first 4 inst vars are actually used by the plugin:
 
 http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/RomePlugin.c
 #define CanvasHandleIndex 0
 #define CanvasTargetIndex 1
 #define CanvasFlagsIndex 2
 #define CanvasStrokeColorIndex 3
 #define CanvasInstSize 8
 
 how did you get that information? from the image side or C code?
 Because I tried to see but unsure.
 
 It's in the C code I linked above. I just reordered it for better 
 readability.
 
 Yes I saw my question was more how do we identify code that is not used 
 anymore?
 We just do the closure over the published primitives and the rest means that 
 it is useful.
 My question was how did you identify that only 4 inst were used and not more. 

If you look at the RomePlugin class you see that 8 class vars are defined. But 
in the generated C code, only the first four are declared. That is because the 
Slang translator only exports the used ones. That's how I know the others are 
unused - they were not exported :)

 The proper fix would be to modify RomePlugin 
 classinitializeInstVarIndices to not generate the indices, but simply 
 hard-code only the used ones (setting CanvasInstSize to 4), and change the 
 comparison John mentioned below to =. Also remove the unused *Index class 
 vars. Now that there are plugins in the wild, hard-coding the indices is a 
 good idea anyway. During development, the flexible generator version was 
 useful, but not anymore.
 
 
 Ok I will browse the RomePlugin class with Cyrille and Jean-Baptiste
 
 
 I browsed a bit the C code and I'm learning so may be my questions are not 
 clever, but 
 
 - do we need the pango primitives for ROME?
 Apparently Pango may use Cairo for fonts rendering but do Rome needs 
 that?
 So is it simpler to use fonts via pango than cairo.
 
 Pango provides word/paragraph layout. Many non-latin scripts (e.g. 
 Devanagari) require glyph shaping, there is no one-to-one mapping between 
 Unicode characters and glyphs rendered in context. Pango can do that. I'm 
 not aware of any other renderer in Squeak that would support this (Yoshiki 
 added it for OLPC). Well, maybe the Unicode plugin from Scratch could do it 
 too, not sure.
 
 - then what about FormInstSize?
 
 (interpreterProxy-slotSizeOf(formOop))  FormInstSize
 does it mean
 
 Same thing. The instance variables actually used by the plugin should be 
 hard coded. Otherwise the same would happen as in Sophie - some inst vars 
 were added to the Canvas, so the inst size compiled into the plugin became 
 larger than necessary.
 
 Btw, by now you probably have guessed that a workaround for the Mac issue 
 would be to add 5 dummy inst vars to RomePluginCanvas just to make the 
 plugin happy.
 
 Yes. In fact my question was more is FormInstSize used (or are the 
 functionality using FormInstSize used)?

If you see it in the C code then yes, it is used.

 I have problems to see how we can clean the C code.
 All my questions should be interpreted with this slant. 

Well, no need to clean the C code because it is just generated. Clean the 
RomePlugin class instead :^)

 It doesn't need to be in sync. But maybe I do not understand the question.
 
 Sorry was not clear.
 My question is how Cairo supports backwards compatibility?
 What happens if the plugin expect a different version of Cairo on the machine?
 May be they do not change their interface?

Many projects are better about backwards compatibility than we are ;)

Generally, once an API was added, it is *never* removed or changed in the same 
major version of a library. Only additions are allowed in point releases. This 
ensures code can dynamically link to older binaries and not break with newer 
releases.

Also, the major version is part of the library name (executables actually link 
against bla.so.1 not bla.so) so multiple major versions of the same library can 
co-exist on a system. So major releases can remove or change existing API.

In short, I wouldn't worry about it - I'm not sure in cairo's particular case 
but in general that's how it works.

There is something to be said about published vs. public interfaces, and in 
Smalltalk we usually don't respect either ...

- Bert -


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Issue tracking system

2010-04-19 Thread Geert Claes


Great, I have just added the Gjallar mailing list to the other Nabble
Smalltlalk onlne forums.

http://n4.nabble.com/Gjallar-f2015723.html
http://n4.nabble.com/Gjallar-f2015723.html 

Göran, if you can export the the archive Nabble is able to import it as a
.mbox file.


-- 
View this message in context: 
http://n4.nabble.com/Issue-tracking-system-tp2013457p2015728.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Setup package fixes

Indeed, please commit it directly in the Setup project.

Cheers,
Doru

On 19 Apr 2010, at 03:54, Levente Uzonyi wrote:

On Sun, 18 Apr 2010, Sean P. DeNigris wrote:

I sent some fixes to the package owner, but also posted a link to
the mcz
file http://seandenigris.com/files/Setup-SeanDeNigris.47.mcz
here , in case

anyone wants it.

Why did't you upload it to the squeaksource repository directly? (http://squeaksource.com/setup.html
)

* Fix - SetupinstallDevelopment - changed from Installer (which
is not

pre-installed in Pharo 1.0) to Gopher.
* Fix - SetupinstallSpecificUser - Changed Author
initials (depreciated

in Pharo 1.0) to author fullName.
- changed all author initials to full names, except jre because I
didn't

know what it stood for.

Probably Jorge Ressia.

Levente

I tested it against Pharo-Core 1.0 PharoCore-1.1-11312-UNSTABLE.
I tried

to port it to Squeak 4.1, but got various errors, so I backed out the
changes. But if you are interested, I can send them to you.

Sean
--
View this message in context:
http://n4.nabble.com/Setup-package-fixes-tp2015309p2015309.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
www.tudorgirba.com

Obvious things are difficult to teach.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo latest announcement

2010-04-19 Thread Sudhakar Krishnamachari



 Is it inadvertent for the version is showing up as 1.0 instead of 1.1...?
 at
 http://pharo-project.org/home
 Version 1.0 (stable)

 Pharo 1.0 was released on April 15, 2010. Download the one-click image and
 get Pharo up and running within seconds.
 http://pharo-project.org/pharo-download/release-1-0

 -Skrish

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Setup package fixes



Tudor Girba wrote:
 
 Indeed, please commit it directly in the Setup project.
 

Done.  I didn't know the etiquette of posting to someone else's repository! 
It even sounds wrong ;-)

Sean 
-- 
View this message in context: 
http://n4.nabble.com/Setup-package-fixes-tp2015309p2015802.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo latest announcement

2010-04-19 Thread Adrian Lienhard

Hi Skrish,

I don't understand your question. Version 1.0 is the current stable one and 1.1 
is the unstable one.

Adrian
 
On Apr 19, 2010, at 13:47 , Sudhakar Krishnamachari wrote:

 
 
 Is it inadvertent for the version is showing up as 1.0 instead of 1.1...?
 at
 http://pharo-project.org/home
 Version 1.0 (stable)
 
 Pharo 1.0 was released on April 15, 2010. Download the one-click image and
 get Pharo up and running within seconds.
 http://pharo-project.org/pharo-download/release-1-0
 
 -Skrish
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

Sig,

Lack of precedence *is* a weakness of the language and ridiculing someone who 
cites it won't help anything.  IMHO, the best response we have is that 
consistency is among Smalltalk's great strengths, and arithmetic precedence was 
and remains a deliberate casualty of that design goal.  I am not saying we 
should change the situation, but grant the point.

If the other side is not willing to accept an extra set of parentheses here and 
there in the name of consistency, you might subsequently try pointing out that 
a nice mix is to do logic, memory management and GUI implementation in 
Smalltalk and to do number crunching in C++ with the functions exposed as 
extern C.  Not only is it faster than a pure-Smalltalk solution, the 
equations translate much as one exects, and C's memory management woes are 
largely irrelevant.

Precedence was indeed a pain to learn as a child, but we all did learn it, and 
the best of us will at times get bitten when the compter does not know those 
same rules.  The trick, is to respectfully challenge people to try this 
wonderful system that is nice enough on balance to get people to re-think 
arithmetic - or at least pitch it that way.

Bill



-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr 
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Sunday, April 18, 2010 11:07 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 16 April 2010 13:10, Henrik Johansen henrik.s.johan...@veloxit.no wrote:

 On Apr 15, 2010, at 10:33 31PM, Adrian Lienhard wrote:

 Thanks, Daniel, for posting on reddit! We currently are almost at the top of 
 the list...


 Cheers,
 Adrian

 Gotta love reddit...
 3 most repeated/discussed topics in comments:
  - I don't know what Smalltalk is, and the site doesn't tell me, not even 
 the about page!
  - SUCKS, I can't use my favourite text-editor and git!
  - 1 + 2 * 3 = 9 WTF SMALLTALK

Oh yeah.. there are two guys battling to the death, each defending own point..
The guy who claims that precedence rules is a must, must be forgot, how much 
pain it was took to learn them in a childhood :)

 :D

 Cheers,
 Henry


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




--
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [CfP] DLS'10

2010-04-19 Thread Pascal Costanza

Dynamic Languages Symposium 2010

October 18, 2010

Co-located with SPLASH (OOPSLA) 2010
In cooperation with ACM SIGPLAN
John Ascuaga's Nugget, Reno/Tahoe, Nevada, USA

http://www.dynamic-languages-symposium.org/dls-10/

* Call for papers *

The 6th Dynamic Languages Symposium (DLS) at the conference formerly known as
OOPSLA is a forum for discussion of dynamic languages, their implementation
and application. While mature dynamic languages including Smalltalk, Lisp,
Scheme, Self, Prolog, and APL continue to grow and inspire new converts, a
new generation of dynamic scripting languages such as Python, Ruby, PHP, Tcl,
and JavaScript are successful in a wide range of applications. DLS provides a
place for researchers and practitioners to come together and share their
knowledge, experience, and ideas for future research and development.

DLS 2010 invites high quality papers reporting original research, innovative
contributions or experience related to dynamic languages, their
implementation and application. Accepted Papers will be published in the ACM
Digital Library.

Areas of interest include but are not limited to:

* Innovative language features and implementation techniques
* Development and platform support, tools
* Interesting applications
* Domain-oriented programming
* Very late binding, dynamic composition, and runtime adaptation
* Reflection and meta-programming
* Software evolution
* Language symbiosis and multi-paradigm languages
* Dynamic optimization
* Hardware support
* Experience reports and case studies
* Educational approaches and perspectives
* Object-oriented, aspect-oriented, and context-oriented programming

=== Submissions and proceedings ===

We invite original contributions that neither have been published previously
nor are under review by other refereed events or publications. Research
papers should describe work that advances the current state of the art.
Experience papers should be of broad interest and should describe insights
gained from substantive practical applications. The program committee will
evaluate each contributed paper based on its relevance, significance,
clarity, and originality.

Accepted papers will be published in the ACM Digital Library.

Papers are to be submitted electronically at
http://www.easychair.org/conferences?conf=dls2010 in PDF format. Submissions
must not exceed 12 pages and need to use the ACM format, templates for which
can be found at http://www.acm.org/sigs/pubs/proceed/template.html.

=== Important dates ===

Submission of papers:  June 1, 2010 (hard deadline)
Author notification:  July 15, 2010
Final versions due: August 13, 2010
DLS 2010:  October 18, 2010
SPLASH/OOPSLA 2010: October 17-21, 2010

=== Program chair ===

William Clinger, Northeastern University, Boston, Massachusetts, USA

=== Program committee ===

Robby Findler (Northwestern University)
Jeffrey S. Foster (University of Maryland)
Lars Thomas Hansen (Adobe Systems)
Charlotte Herzeel (University of Brussels)
S. Alexander Spoon (Google)
Eric Tanter (University of Chile)
Jan Vitek (Purdue University)
Alessandro Warth (Viewpoints Research Institute)

[to be completed]

-- 
Pascal Costanza, mailto:p...@p-cos.net, http://p-cos.net
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium







___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 19 April 2010 15:20, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote:
 Sig,

 Lack of precedence *is* a weakness of the language and ridiculing someone who 
 cites it won't help anything.  IMHO, the best response we have is that 
 consistency is among Smalltalk's great strengths, and arithmetic precedence 
 was and remains a deliberate casualty of that design goal.  I am not saying 
 we should change the situation, but grant the point.

 If the other side is not willing to accept an extra set of parentheses here 
 and there in the name of consistency, you might subsequently try pointing out 
 that a nice mix is to do logic, memory management and GUI implementation in 
 Smalltalk and to do number crunching in C++ with the functions exposed as 
 extern C.  Not only is it faster than a pure-Smalltalk solution, the 
 equations translate much as one exects, and C's memory management woes are 
 largely irrelevant.

 Precedence was indeed a pain to learn as a child, but we all did learn it, 
 and the best of us will at times get bitten when the compter does not know 
 those same rules.  The trick, is to respectfully challenge people to try this 
 wonderful system that is nice enough on balance to get people to re-think 
 arithmetic - or at least pitch it that way.


the thing is, that smalltalk expression a+b*c not necessary related to
arithmetics.
I could create own class with #+ and #* selectors which can do
anything i want, doing things way different to be any kind of math.
Also, in a school terms, a precedence rules is defined for very small
set of operators, while in smalltalk we could define a new one
at any time using binary selector syntax. Now imagine, that each time
you creating a new operator, you must
a) define its precedence
b) remember how to use it.
Now think, how hard it would be for someone to read your code and
understand the semantics, since he doesn't knows what precedence you
are defined for new operator(s).
Another problem that if you defining a new operator and its
precedence, a precedence tends to be globally applied. Now what you
would do, if you filing in the code, in which a precedence for some
operators doesn't matching the precedence of those, which already in
image?
Also, mathematicians using different kinds of algebras for different
domains, and defining different and weird looking operators in that
algebras.

So, that's why i think its completely pointless to even think about
supporting precedence rules in smalltalk, by breaking its uniform and
_simple_ syntax rules.

 Bill



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

Sig,

You are missing the point: I *agree* that supporting precedence rules would 
very likely be bad and I would probably argue against any such change.  Where 
you are doing damage to us all is by ridiculing someone who is raising a valid 
concern rather than debating that person with reasoned arguments.

Bill



-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr 
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Monday, April 19, 2010 8:41 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 19 April 2010 15:20, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote:
 Sig,

 Lack of precedence *is* a weakness of the language and ridiculing someone who 
 cites it won't help anything.  IMHO, the best response we have is that 
 consistency is among Smalltalk's great strengths, and arithmetic precedence 
 was and remains a deliberate casualty of that design goal.  I am not saying 
 we should change the situation, but grant the point.

 If the other side is not willing to accept an extra set of parentheses here 
 and there in the name of consistency, you might subsequently try pointing out 
 that a nice mix is to do logic, memory management and GUI implementation in 
 Smalltalk and to do number crunching in C++ with the functions exposed as 
 extern C.  Not only is it faster than a pure-Smalltalk solution, the 
 equations translate much as one exects, and C's memory management woes are 
 largely irrelevant.

 Precedence was indeed a pain to learn as a child, but we all did learn it, 
 and the best of us will at times get bitten when the compter does not know 
 those same rules.  The trick, is to respectfully challenge people to try this 
 wonderful system that is nice enough on balance to get people to re-think 
 arithmetic - or at least pitch it that way.


the thing is, that smalltalk expression a+b*c not necessary related to 
arithmetics.
I could create own class with #+ and #* selectors which can do anything i want, 
doing things way different to be any kind of math.
Also, in a school terms, a precedence rules is defined for very small set of 
operators, while in smalltalk we could define a new one at any time using 
binary selector syntax. Now imagine, that each time you creating a new 
operator, you must
a) define its precedence
b) remember how to use it.
Now think, how hard it would be for someone to read your code and understand 
the semantics, since he doesn't knows what precedence you are defined for new 
operator(s).
Another problem that if you defining a new operator and its precedence, a 
precedence tends to be globally applied. Now what you would do, if you filing 
in the code, in which a precedence for some operators doesn't matching the 
precedence of those, which already in image?
Also, mathematicians using different kinds of algebras for different domains, 
and defining different and weird looking operators in that algebras.

So, that's why i think its completely pointless to even think about supporting 
precedence rules in smalltalk, by breaking its uniform and _simple_ syntax 
rules.

 Bill



--
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

2010-04-19 Thread Randal L. Schwartz

 Schwab,Wilhelm == Schwab,Wilhelm K bsch...@anest.ufl.edu writes:

Wilhelm Lack of precedence *is* a weakness of the language and
Wilhelm ridiculing someone who cites it won't help anything.

Until you're able to reframe it as a problem of familiarity.  Sure,
most people learned programming (and algebra) with precedence rules.

But precedence is not inherently the most natural thing.  And this is
what you must make clear.

Look at the contortions that happen when you have a language that has
either user-defined operators (prolog comes to mind) or just a hella
lotta levels (Perl has 40 levels of precedence).  The point is that you
*cannot*, even as a reasonably intelligent human being, parse such
languages *locally* to tell what the order of ops are.  You *must*
consult something external, which can be pretty crazy if it means
hunting through source code instead of just looking it up on a ref card.

Smalltalk's way is very simple.  Sure, it's not optimized for the most
common case (multiplication over addition), but it's optimized for *all*
the other cases.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Fonts for dummies

Hello all,

What is the best way to create/access fonts?  So far, TextStyle defaultFont 
seems to work.  I was about to write that I was feeling lost otherwise when I 
recalled setting fonts by name in Migrate, and a comment therein reveals that I 
stole some preferences from Lukas who used LogicalFont.  Perhaps specifying the 
family name following his example (with cues from exploring LogicalFont all) is 
the answer?

What about what Microsoft (sorry...) calls font metrics?  By involving a device 
context (canvas in our world), one can find out how big a particular string 
will be on the target device's resolution, and allowing for kerning.

So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which 
means they know nothing of the intended device, and do not (obviously anyway) 
seem to know about kerning.  Are there glaringly missing features here, or is 
this simply an consequence of printing being done via PostScript and therefore 
still in terms of point sizes?

Bill




___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 19 April 2010 16:53, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote:
 Sig,

 You are missing the point: I *agree* that supporting precedence rules would 
 very likely be bad and I would probably argue against any such change.  Where 
 you are doing damage to us all is by ridiculing someone who is raising a 
 valid concern rather than debating that person with reasoned arguments.


I am serious. If you can't learn the simplest syntax rules, you can't
learn anything else.
And i don't care about what such people thinking, because they will
never try to think different.
They are found that moving in direction where crowd moves, is a best
way. Its not interesting to them, if there are other directions, and
some even doesn't interesting in what direction they are currently
moving. They are told to move in that way and they moving.

Fine. Let this mindless crowd go its way. I don't feel a loss.

 Bill




-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

2010-04-19 Thread Henrik Johansen


On Apr 19, 2010, at 4:16 25PM, Schwab,Wilhelm K wrote:

 
 What about what Microsoft (sorry...) calls font metrics?  By involving a 
 device context (canvas in our world), one can find out how big a particular 
 string will be on the target device's resolution, and allowing for kerning.
 
 So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which 
 means they know nothing of the intended device, and do not (obviously anyway) 
 seem to know about kerning.  Are there glaringly missing features here, or is 
 this simply an consequence of printing being done via PostScript and 
 therefore still in terms of point sizes?
 
 Bill

StrikeFonts take their glyphs from a bitmap, thus will have constant pixel 
sizes. (decentKern is used for italic glyphs though)
As far as I know, kerning is not done for StrikeFonts, the only related use is 
of ascentKern when making a bitmap for italic derivatives of basefonts.
Changing StrikeFonts to include kerning info will mean rewriting the 
string-rendering primitive, so I wouldn't get my hopes up it is likely to 
happen anytime soon.


For FreeTypeFonts, getWidthOf: uses AbstractFontpixelSize, which again uses 
TextStylepointsToPixels: , which relies on TextStylespixelsPerInch.
pixelsPerInch _could_ be set based on information gathered at startup about 
resolution and screen size, but is not done currently, so a default of 96 is 
used.
FreeTypeFont widthOfString:from:to: returns a width which takes kerning into 
account. (in theory, see the comment for clarifications)

In essence, if those features are important to you:
- Use FreeTypeFonts.
- Set TextStyle pixelsPerInch: to a computed value at startup.

Cheers,
Henry



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

On 19 April 2010 17:16, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote:
 Hello all,

 What is the best way to create/access fonts?  So far, TextStyle defaultFont 
 seems to work.  I was about to write that I was feeling lost otherwise when I 
 recalled setting fonts by name in Migrate, and a comment therein reveals that 
 I stole some preferences from Lukas who used LogicalFont.  Perhaps specifying 
 the family name following his example (with cues from exploring LogicalFont 
 all) is the answer?

 What about what Microsoft (sorry...) calls font metrics?  By involving a 
 device context (canvas in our world), one can find out how big a particular 
 string will be on the target device's resolution, and allowing for kerning.

 So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which 
 means they know nothing of the intended device, and do not (obviously anyway) 
 seem to know about kerning.  Are there glaringly missing features here, or is 
 this simply an consequence of printing being done via PostScript and 
 therefore still in terms of point sizes?


I think there is a _glaringly missing features here_.
The fonts in squeak seems evolved from being a simple raster bitmaps,
and don't quite well resembling a functionality beyond this.

 Bill




 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

Sig,

Never argue with an idiot - others might not be able to tell the difference.  I 
beg you to raise the level of your arguments beyond name calling.  Whether you 
see it that way or not, you mention childhood and it's over.

Bill 



-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr 
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Monday, April 19, 2010 9:27 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 19 April 2010 16:53, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote:
 Sig,

 You are missing the point: I *agree* that supporting precedence rules would 
 very likely be bad and I would probably argue against any such change.  Where 
 you are doing damage to us all is by ridiculing someone who is raising a 
 valid concern rather than debating that person with reasoned arguments.


I am serious. If you can't learn the simplest syntax rules, you can't learn 
anything else.
And i don't care about what such people thinking, because they will never try 
to think different.
They are found that moving in direction where crowd moves, is a best way. Its 
not interesting to them, if there are other directions, and some even doesn't 
interesting in what direction they are currently moving. They are told to move 
in that way and they moving.

Fine. Let this mindless crowd go its way. I don't feel a loss.

 Bill




--
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 19 April 2010 18:10, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote:
 Sig,

 Never argue with an idiot - others might not be able to tell the difference.  
 I beg you to raise the level of your arguments beyond name calling.  Whether 
 you see it that way or not, you mention childhood and it's over.


I am not using reddit. And indeed, a flame wars it a least interesting
thing i wanna be part of.
The point is, that smalltalk gives a clear answer (as to me), why it
has such syntax: uniformity, simplicity and consistency.
While in many other languages such answer could be depicted as:
because others do.

So, a central question in such discussions should be _why_ some
language having such rules, and those who don't bother asking it, but
instead, from a very start saying that its awfully bad, not worth my
attention :)

 Bill



 -Original Message-
 From: pharo-project-boun...@lists.gforge.inria.fr 
 [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor 
 Stasenko
 Sent: Monday, April 19, 2010 9:27 AM
 To: Pharo-project@lists.gforge.inria.fr
 Subject: Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

 On 19 April 2010 16:53, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote:
 Sig,

 You are missing the point: I *agree* that supporting precedence rules would 
 very likely be bad and I would probably argue against any such change.  
 Where you are doing damage to us all is by ridiculing someone who is raising 
 a valid concern rather than debating that person with reasoned arguments.


 I am serious. If you can't learn the simplest syntax rules, you can't learn 
 anything else.
 And i don't care about what such people thinking, because they will never try 
 to think different.
 They are found that moving in direction where crowd moves, is a best way. Its 
 not interesting to them, if there are other directions, and some even doesn't 
 interesting in what direction they are currently moving. They are told to 
 move in that way and they moving.

 Fine. Let this mindless crowd go its way. I don't feel a loss.

 Bill




 --
 Best regards,
 Igor Stasenko AKA sig.

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

2010-04-19 Thread Michael Haupt

Hi,

On Mon, Apr 19, 2010 at 4:26 PM, Igor Stasenko siguc...@gmail.com wrote:
 I am serious. If you can't learn the simplest syntax rules, you can't
 learn anything else.

but Syntax, dearest Igor, is key! And Note The Capital S!

You see, Lisp clearly sucks because it has too many brackets. Python
and Haskell are most unfavourable because they have whitespace with
semantics. Pascal, Modula-2, and Ada are way too verbose. Forth
organises programs in pages - now *that* is bureaucratic and
old-fashioned, aye? Smalltalk obviously doesn't know how to compute
with natural numbers properly. Smalltalk, Self, and Io share the
indignity of not even having proper keywords. Java, Scala, C, and C++
... don't even get me started, man: curly braces are so 80s.
Erlang does not end sentences with an exclamation mark, it puts it in
their midst - how messy, bah. In Prolog, you have to write your own
rules, which makes it seem as if the language didn't have any: yuck!

If you consider all these points wisely, you will inevitably come to
the conclusion that the only language with a proper, clear, civilised,
and tidy syntax out there is brainfuck. Some argue it's unacceptable
due to its name, but that is not a syntactical argument and hence
invalid. I win.

Best,

Michael

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On Monday, April 19, 2010, Adrian Lienhard a...@netstyle.ch wrote:
 On Apr 19, 2010, at 09:10 , Stéphane Ducasse wrote:

 On Apr 19, 2010, at 1:56 AM, Stephen Taylor wrote:

 Henrik Johansen wrote:

 Gotta love reddit...
 [...]
 - I don't know what Smalltalk is, and the site doesn't tell me, not even 
 the about page!

 That one I think is legitimate - and not just for Pharo but for almost 
 every Open Source project out there. I think every project's home page 
 should keep first time in visitors in mind. (My very least favourite thing 
 for the first page of a site is to see the project commit log - talk about 
 unwelcoming!).

 Good remark.
 Thanks.
 Does anybody have some text we could reuse?

 I think that anybody that is enough interested will be able to type 
 Smalltalk into Google. Next, people are going to ask what a programming 
 language is, and we have to explain that too ;)

 Anyway, couldn't we just link the first occurrence of Smalltalk to 
 en.wikipedia.org/wiki/Smalltalk?


I already did that ;-) Cheers
mike


 And to say something positive - Pharo 1.0 looks great - solid and serious 
 and workable. A couple of my co-workers have called my bluff and asked for 
 a Smalltalk tutorial, and I'll be happy to show them Pharo.

 Thanks :)

 Cheers,
 Adrian
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 19 April 2010 19:40, Michael Haupt mha...@gmail.com wrote:
 Hi,

 On Mon, Apr 19, 2010 at 4:26 PM, Igor Stasenko siguc...@gmail.com wrote:
 I am serious. If you can't learn the simplest syntax rules, you can't
 learn anything else.

 but Syntax, dearest Igor, is key! And Note The Capital S!

 You see, Lisp clearly sucks because it has too many brackets. Python
 and Haskell are most unfavourable because they have whitespace with
 semantics. Pascal, Modula-2, and Ada are way too verbose. Forth
 organises programs in pages - now *that* is bureaucratic and
 old-fashioned, aye? Smalltalk obviously doesn't know how to compute
 with natural numbers properly. Smalltalk, Self, and Io share the
 indignity of not even having proper keywords. Java, Scala, C, and C++
 ... don't even get me started, man: curly braces are so 80s.
 Erlang does not end sentences with an exclamation mark, it puts it in
 their midst - how messy, bah. In Prolog, you have to write your own
 rules, which makes it seem as if the language didn't have any: yuck!

 If you consider all these points wisely, you will inevitably come to
 the conclusion that the only language with a proper, clear, civilised,
 and tidy syntax out there is brainfuck. Some argue it's unacceptable
 due to its name, but that is not a syntactical argument and hence
 invalid. I win.


I agree. all languages having bright and dark sides.
And people free to choose what they like (or not).

I wonder, how a computer languages would look like for europeans, if
they are first were invented
by Chinese or Japanes cultures. ( you know, they would use glyphs in it ;).
Still, there are an univestal laws and concepts which come from
mathematics, and will not change
depending on cultural/educational nuances: computers are finite state
machines with strictly defined order of operations.
Computer always 'knows' what next operation it going to perform, and
don't need to use any precedence.

If we ever will meet aliens, then to start communicating we, no doubt,
should use an universal rules  semantics, which can be interpreted
without any chances to be ambiguous. And precedence, obviously is not
a univesal :)

 Best,

 Michael

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

2010-04-19 Thread Michael Haupt

Hi Igor,

On Mon, Apr 19, 2010 at 7:21 PM, Igor Stasenko siguc...@gmail.com wrote:
 Computer always 'knows' what next operation it going to perform, and
 don't need to use any precedence.

... enter quantum computers. :-P

 If we ever will meet aliens, then to start communicating we, no doubt,
 should use an universal rules  semantics, which can be interpreted
 without any chances to be ambiguous. And precedence, obviously is not
 a univesal :)

Hear, hear!

Best,

Michael

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Zoomable UI

This is where, i think we should be heading:

http://ahead.com

And this is why i think, a graphics frameworks should be vector based,
not a pixel based one.


-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'


http://code.google.com/p/pharo/issues/detail?id=2327 :
Pharo image: core
Pharo core version: PharoCore1.1ALPHA #11312
Virtual machine used: Squeak 4.2.4beta1U (Mac)
Class browser used if applicable:  Browser

Steps to reproduce:
1. Click System-Software Update

'Error: can''t find EOCD position'
-- 
View this message in context: 
http://n4.nabble.com/Error-when-Loading-11313-Pha-CleaningCompilerTests-tp2016295p2016295.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 19 April 2010 20:29, Michael Haupt mha...@gmail.com wrote:
 Hi Igor,

 On Mon, Apr 19, 2010 at 7:21 PM, Igor Stasenko siguc...@gmail.com wrote:
 Computer always 'knows' what next operation it going to perform, and
 don't need to use any precedence.

 ... enter quantum computers. :-P

let me rephrase that:
by building any machine, we using a certain set of principles, on
which it will function.
So then, we could _predict_ how it will behave, if we provide a set of
instructions.
That's why i put 'knows'. Computers, obviously don't know anything.
Knowledge comes from the fact, on which principles you built a machine,
so you can predict what will happen if you instruct it to do one or
another operation.

 If we ever will meet aliens, then to start communicating we, no doubt,
 should use an universal rules  semantics, which can be interpreted
 without any chances to be ambiguous. And precedence, obviously is not
 a univesal :)

 Hear, hear!

 Best,

 Michael

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Zoomable UI


I would be a very happy user for something line that :)

Doru


On 19 Apr 2010, at 19:32, Igor Stasenko wrote:


This is where, i think we should be heading:

http://ahead.com

And this is why i think, a graphics frameworks should be vector based,
not a pixel based one.


--
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


--
www.tudorgirba.com

Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge.




___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [Job] Smalltalker needed at Zurich

Dear Smalltalkers :)

 Dear Sir/Madam,
  
 I’ve been referred to you by one of your members. I’m currently looking for a 
 Smalltalk Developer to work for an Investment Bank in Zurich. The initial 
 contract is for 12 months with the likelihood of staying there for about 3 
 years. They are looking for people with recent experience of Development in 
 Smalltalk and who have experience of Gemstone also. The role is to start in 
 the coming months. If you know anyone currently looking for opportunities or 
 people who would be interested, I would be most grateful if you could forward 
 my details.
  
 Kind Regards,
  
 Danny Shaw
  
  
 Kind Regards / Freundliche Grüsse / Meilleures salutations
  
 Mr Danny Shaw
 Consultant – Europe IT Division Recruitment / Arbeitsvermittlung
 Nicoll Curtin Limited
 Tel:  +44 207 397 0135
 Email:  danny.s...@nicollcurtin.co.uk
 My LinkedIn Profile:
 http://www.linkedin.com/in/dannyjshaw
  
 Please consider the environment before printing this e-mail
  
 LEGAL DISCLAIMER
 The contents of this email and any transmitted files are confidential and 
 intended solely for the use of the individual or entity to whom they are 
 addressed. We hereby exclude any warranty and any liability as to the quality 
 or accuracy of the contents of this email and any attached transmitted files. 
 If you are not the intended recipient, be advised that you have received this 
 email in error and that any use, dissemination, forwarding, printing or 
 copying of this email is strictly prohibited. If you have received this email 
 in error please contact the sender and delete the material from any computer. 
 Nicoll Curtin Technology Limited is registered at the address above, in 
 England  Wales, under number 04704369.
  

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Zoomable UI

Yes!
if you ask me I would have loved that Squeak develops such vision and pharo 
deals with the low level ugly bits.
This would have been a clear win-win situation...

Stef

On Apr 19, 2010, at 7:32 PM, Igor Stasenko wrote:

 This is where, i think we should be heading:
 
 http://ahead.com
 
 And this is why i think, a graphics frameworks should be vector based,
 not a pixel based one.
 
 
 -- 
 Best regards,
 Igor Stasenko AKA sig.
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Zoomable UI

igor

do you think that we got have a svg canvas: as a merge between what you show us 
at Brest -- with the tiger and using the rome cnavas -- having a dedicated 
subclass for svg.

Stef

On Apr 19, 2010, at 7:32 PM, Igor Stasenko wrote:

 This is where, i think we should be heading:
 
 http://ahead.com
 
 And this is why i think, a graphics frameworks should be vector based,
 not a pixel based one.
 
 
 -- 
 Best regards,
 Igor Stasenko AKA sig.
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

2010-04-19 Thread csrabak

Em 19/04/2010 14:21, Igor Stasenko  siguc...@gmail.com  escreveu:

 On 19 April 2010 19:40, Michael Haupt wrote:
  Hi,
  On Mon, Apr 19, 2010 at 4:26 PM, Igor Stasenko wrote:
  I am serious.  If you can't learn the  simplest syntax rules, you
  can't learn anything else.
  but Syntax, dearest Igor, is key! And Note The Capital S!
  You   see,  Lisp   clearly   sucks  because   it   has  too   many
  brackets. Python  and Haskell  are most unfavourable  because they
  have whitespace with semantics.  Pascal, Modula-2, and Ada are way
  too verbose.  Forth organises  programs in pages  - now  *that* is
  bureaucratic and  old-fashioned, aye? Smalltalk  obviously doesn't
  know  how to  compute  with natural  numbers properly.  Smalltalk,
  Self,  and  Io share  the  indignity  of  not even  having  proper
  keywords. Java, Scala,  C, and C++ ... don't  even get me started,
  man: curly braces  are so 80s.  Erlang does  not end sentences
  with an exclamation  mark, it puts it in their  midst - how messy,
  bah. In Prolog,  you have to write your own  rules, which makes it
  seem as if the language didn't have any: yuck!
  If you consider all these  points wisely, you will inevitably come
  to the  conclusion that  the only language  with a  proper, clear,
  civilised, and tidy syntax out there is brainfuck. Some argue it's
  unacceptable  due to  its  name,  but that  is  not a  syntactical
  argument and hence invalid. I win.
 
  I agree.  all languages having  bright and dark sides.   And people
 free to choose what they like (or not).
  I wonder, how  a computer languages would look  like for europeans,
 if they  are first were invented  by Chinese or  Japanes cultures. (
 you  know, they  would use  glyphs in  it ;).  

I could not be totally positive on this, but I think  the better proxy 
we have for that is APL which used some special symbols and even needed
a special keyboard for it!

--
Cesar Rabak

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Zoomable UI

On 19 April 2010 21:41, Stéphane Ducasse stephane.duca...@inria.fr wrote:
 igor

 do you think that we got have a svg canvas: as a merge between what you show 
 us at Brest -- with the tiger and using the rome cnavas -- having a dedicated 
 subclass for svg.


Well, the problem is, that the above frameworks putting us into a constraints.
While, we can do things like that
(http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html)
ourselves, without using 3rd party stuff.

I know, it sounds like NIH syndrome, but i am concerned, that using
rome or svg we will be able to render a 10 browser windows on a
desktop with 25 frames/second rate.
The above stuff may be fast enough, when you updating only a portions
of the display surface (like currently Morphic does and optimized for
that).
But things like zoom-in or zoom out, obviously require a full desktop
update at each frame, so we need a framework which can support a
decent frame rate for this.
This means, that such framework should not rely on a
techniques/optimizations, which require updating only a portions of
screen,
but instead, its throughput should be high enough to redraw a full
screen each 1/25 second.

 Stef

 On Apr 19, 2010, at 7:32 PM, Igor Stasenko wrote:

 This is where, i think we should be heading:

 http://ahead.com

 And this is why i think, a graphics frameworks should be vector based,
 not a pixel based one.


 --
 Best regards,
 Igor Stasenko AKA sig.

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

2010-04-19 Thread csrabak


 



Em 19/04/2010 14:53, Igor Stasenko  siguc...@gmail.com  escreveu:

 On 19 April 2010 20:29, Michael Haupt wrote:
  Hi Igor,
  On Mon, Apr 19, 2010 at 7:21 PM, Igor Stasenko wrote:
  Computer always 'knows' what  next operation it going to perform,
  and don't need to use any precedence.
  ... enter quantum computers. :-P
  let me rephrase that: by  building any machine, we using a certain
 set of  principles, on  which it will  function.  So then,  we could
 _predict_ how it  will behave, if we provide  a set of instructions.

NO. As historical counter examples there are the Neural net based computer 
http://en.wikipedia.org/wiki/Perceptrons which was built as a machine, 
or the homeostat http://en.wikipedia.org/wiki/Homeostat (ditto).

my 0.01...

--
Cesar Rabak

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

That will take some (re)reading, but is much appreciated.  The fact that the 
Canvas is not involved is deeply discouraging: one should not have to edit a 
class method in order to involve a higher-resolution output device :(

Bill


-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr 
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik 
Johansen
Sent: Monday, April 19, 2010 9:47 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fonts for dummies


On Apr 19, 2010, at 4:16 25PM, Schwab,Wilhelm K wrote:

 
 What about what Microsoft (sorry...) calls font metrics?  By involving a 
 device context (canvas in our world), one can find out how big a particular 
 string will be on the target device's resolution, and allowing for kerning.
 
 So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which 
 means they know nothing of the intended device, and do not (obviously anyway) 
 seem to know about kerning.  Are there glaringly missing features here, or is 
 this simply an consequence of printing being done via PostScript and 
 therefore still in terms of point sizes?
 
 Bill

StrikeFonts take their glyphs from a bitmap, thus will have constant pixel 
sizes. (decentKern is used for italic glyphs though) As far as I know, kerning 
is not done for StrikeFonts, the only related use is of ascentKern when making 
a bitmap for italic derivatives of basefonts.
Changing StrikeFonts to include kerning info will mean rewriting the 
string-rendering primitive, so I wouldn't get my hopes up it is likely to 
happen anytime soon.


For FreeTypeFonts, getWidthOf: uses AbstractFontpixelSize, which again uses 
TextStylepointsToPixels: , which relies on TextStylespixelsPerInch.
pixelsPerInch _could_ be set based on information gathered at startup about 
resolution and screen size, but is not done currently, so a default of 96 is 
used.
FreeTypeFont widthOfString:from:to: returns a width which takes 
FreeTypeFont kerning into account. (in theory, see the comment for 
FreeTypeFont clarifications)

In essence, if those features are important to you:
- Use FreeTypeFonts.
- Set TextStyle pixelsPerInch: to a computed value at startup.

Cheers,
Henry



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

On 19 April 2010 22:04,  csra...@bol.com.br wrote:





 Em 19/04/2010 14:53, Igor Stasenko  siguc...@gmail.com  escreveu:

 On 19 April 2010 20:29, Michael Haupt wrote:
  Hi Igor,
  On Mon, Apr 19, 2010 at 7:21 PM, Igor Stasenko wrote:
  Computer always 'knows' what  next operation it going to perform,
  and don't need to use any precedence.
  ... enter quantum computers. :-P
  let me rephrase that: by  building any machine, we using a certain
 set of  principles, on  which it will  function.  So then,  we could
 _predict_ how it  will behave, if we provide  a set of instructions.

 NO. As historical counter examples there are the Neural net based computer
 http://en.wikipedia.org/wiki/Perceptrons

And where is a contradiction?
A first two paragraphs on that page describing a principles on which it built.
And then, you saying that you can't predict how it behaves after you
built it using these principles?

 which was built as a machine,
 or the homeostat http://en.wikipedia.org/wiki/Homeostat (ditto).

 my 0.01...

 --
 Cesar Rabak

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

I'm not sure how to read it's not the kerning you are looking for.  What I am 
trying to discover is how to get the exact pixel size of '0x' and of 
'suffix AV' - the latter will potentially involve more kerning than the former.

If this were being done correctly, one would need not only the output device 
and the font, but also the exact text.  It appears there is room to grow.

Bill


-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr 
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik 
Johansen
Sent: Monday, April 19, 2010 9:50 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fonts for dummies


On Apr 19, 2010, at 4:47 17PM, Henrik Johansen wrote:

 
 StrikeFonts take their glyphs from a bitmap, thus will have constant 
 pixel sizes. (decentKern is used for italic glyphs though) As far as I know, 
 kerning is not done for StrikeFonts, the only related use is of ascentKern 
 when making a bitmap for italic derivatives of basefonts.
 

Arr. Correction; the only place StrikeFonts use something with a name related 
to kerning is when doing something with Italics, can't remember exactly how, 
why, or what methods. :) In any case it's not the kerning you are looking for.

Cheers,
Henry
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies


On Apr 19, 2010, at 9:10 PM, Schwab,Wilhelm K wrote:

 That will take some (re)reading, but is much appreciated.  The fact that the 
 Canvas is not involved is deeply discouraging: one should not have to edit a 
 class method in order to involve a higher-resolution output device :(

which method?
open a clear bug entry or request for improvement
Stef

 
 Bill
 
 
 -Original Message-
 From: pharo-project-boun...@lists.gforge.inria.fr 
 [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik 
 Johansen
 Sent: Monday, April 19, 2010 9:47 AM
 To: Pharo-project@lists.gforge.inria.fr
 Subject: Re: [Pharo-project] Fonts for dummies
 
 
 On Apr 19, 2010, at 4:16 25PM, Schwab,Wilhelm K wrote:
 
 
 What about what Microsoft (sorry...) calls font metrics?  By involving a 
 device context (canvas in our world), one can find out how big a particular 
 string will be on the target device's resolution, and allowing for kerning.
 
 So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which 
 means they know nothing of the intended device, and do not (obviously 
 anyway) seem to know about kerning.  Are there glaringly missing features 
 here, or is this simply an consequence of printing being done via PostScript 
 and therefore still in terms of point sizes?
 
 Bill
 
 StrikeFonts take their glyphs from a bitmap, thus will have constant pixel 
 sizes. (decentKern is used for italic glyphs though) As far as I know, 
 kerning is not done for StrikeFonts, the only related use is of ascentKern 
 when making a bitmap for italic derivatives of basefonts.
 Changing StrikeFonts to include kerning info will mean rewriting the 
 string-rendering primitive, so I wouldn't get my hopes up it is likely to 
 happen anytime soon.
 
 
 For FreeTypeFonts, getWidthOf: uses AbstractFontpixelSize, which again uses 
 TextStylepointsToPixels: , which relies on TextStylespixelsPerInch.
 pixelsPerInch _could_ be set based on information gathered at startup about 
 resolution and screen size, but is not done currently, so a default of 96 is 
 used.
 FreeTypeFont widthOfString:from:to: returns a width which takes 
 FreeTypeFont kerning into account. (in theory, see the comment for 
 FreeTypeFont clarifications)
 
 In essence, if those features are important to you:
 - Use FreeTypeFonts.
 - Set TextStyle pixelsPerInch: to a computed value at startup.
 
 Cheers,
 Henry
 
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

2010-04-19 Thread Henrik Sperre Johansen


 On 19.04.2010 21:10, Schwab,Wilhelm K wrote:

That will take some (re)reading, but is much appreciated.  The fact that the 
Canvas is not involved is deeply discouraging: one should not have to edit a 
class method in order to involve a higher-resolution output device :(
Please note, the output device in your definition, and a Canvas as 
defined in Squeak/Pharo, are two different things.
A canvas does not know the physical dimensions of the display device its 
raster will be displayed on.
Thus using it when rendering will not make any difference, but the 
TextStylespixelsPerInch setting does what you'd like (for FreeType fonts).


Repeated for clarity:

In essence, if those features are important to you:
- Use FreeTypeFonts.
- Set TextStyle pixelsPerInch: to a computed value at startup.
The computed value here meaning: Whatever you somehow manage to find 
out is the correct physical proportion.


Cheers,
Henry

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] we need help for rome

2010-04-19 Thread John M McIntosh

On 2010-04-19, at 12:12 AM, Stéphane Ducasse wrote:

 probably :)
 one coming from sophie and one coming from the repository.
 We will fix that as soon as we can make it run on mac (ok we just have to add 
 the inst var) but would be nice to have a clean
 plugin but I imagine that john is stressed with the Scratch problem.
 
 Stef



Well nothing a good night of sleep can't cure. 
I'm trying to build a new plugin based on the current squeaksource.com stuff. 
However MacPorts is busy grinding thru a build(s) for the thousand or so 
components to build freetype  pango  etc, since it's building a universal 
ppc, i386, x86_64 binary on an older G4 laptop running 10.5.  Likely run for 
hours... 

--
===
John M. McIntosh john...@smalltalkconsulting.com   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===






smime.p7s
Description: S/MIME cryptographic signature
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

2010-04-19 Thread Henrik Sperre Johansen


 On 19.04.2010 21:17, Stéphane Ducasse wrote:

On Apr 19, 2010, at 9:10 PM, Schwab,Wilhelm K wrote:


That will take some (re)reading, but is much appreciated.  The fact that the 
Canvas is not involved is deeply discouraging: one should not have to edit a 
class method in order to involve a higher-resolution output device :(

which method?
open a clear bug entry or request for improvement
Stef

It's not a class-method, it's a setting, set by f.ex:
TextStyle pixelsPerInch: 72. (Try changing it to something other than 96 
while using a FreeType font somewhere, and you can see the text size 
changing)


Ideally there'd be code which gathers this value from the system at 
image startup, I'm not aware if such code exists though.

Cheers,
Henry

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

2010-04-19 Thread Henrik Sperre Johansen


 On 19.04.2010 21:16, Schwab,Wilhelm K wrote:

I'm not sure how to read it's not the kerning you are looking for.
Read it as if you meant kerning in the sense that the width of a string 
~= width of each individual character i.e., the ascent/descentKerns in 
StrikeFonts are not used for this.

  What I am trying to discover is how to get the exact pixel size of '0x' 
and of 'suffix AV' - the latter will potentially involve more kerning than the 
former.
When rendered by StrikeFonts, no, they will not, since it does not do 
kerning.

For FreeTypeFonts, #widthOfString:from:to: does exactly what you ask.
It wouldn't be impossible to add kerning to StrikeFonts, but it's a 
fairly major task as you'd need to:
- Update the StrikeFont class to include kerningInfo, and implement 
kerningLeft:right: method

- Define font construction methods etc.
- Actually define useful kerning values for fonts in use.
- Update the displayString: primitive to take into account kerning info

Basically, the support is just not there at all at the moment for 
StrikeFont kerning.


Cheers,
Henry

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'

Hi, I think this is a common error caused by corrupt mcz files. Can
you clear your cache and try again?

thanks,
Mike

On Mon, Apr 19, 2010 at 6:47 PM, Sean P. DeNigris s...@clipperadams.com wrote:

 http://code.google.com/p/pharo/issues/detail?id=2327 :
 Pharo image: core
 Pharo core version: PharoCore1.1ALPHA #11312
 Virtual machine used: Squeak 4.2.4beta1U (Mac)
 Class browser used if applicable:  Browser

 Steps to reproduce:
 1. Click System-Software Update

 'Error: can''t find EOCD position'
 --
 View this message in context: 
 http://n4.nabble.com/Error-when-Loading-11313-Pha-CleaningCompilerTests-tp2016295p2016295.html
 Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'


 Hi, I think this is a common error caused by corrupt mcz files. Can 
 you clear your cache and try again? 
Sure, how do I clear the cache?  Also, it was a totally fresh image downloaded 
from the site.

Sean DeNigris

-- 
View this message in context: 
http://n4.nabble.com/Error-when-Loading-11313-Pha-CleaningCompilerTests-tp2016295p2016517.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] we need help for rome

 probably :)
 one coming from sophie and one coming from the repository.
 We will fix that as soon as we can make it run on mac (ok we just have to 
 add the inst var) but would be nice to have a clean
 plugin but I imagine that john is stressed with the Scratch problem.
 
 Stef
 
 
 Well nothing a good night of sleep can't cure. 
 I'm trying to build a new plugin based on the current squeaksource.com stuff. 
 However MacPorts is busy grinding thru a build(s) for the thousand or so 
 components to build freetype  pango  etc, since it's building a universal 
 ppc, i386, x86_64 binary on an older G4 laptop running 10.5.  Likely run for 
 hours... 


oh yes I know the syndrome. Last time took me 5-6 hours for recompiling 
everything or what is just gtk :)
What we will do is that I would like that this knowledge/burden is shared so we 
will give a try with jean-baptiste and cyrille
to regenerate a plugin and compile it But we will see and learn a lot I 
imagine in the process. 

 
 --
 ===
 John M. McIntosh john...@smalltalkconsulting.com   Twitter:  squeaker68882
 Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
 ===
 
 
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'

there is a directory package-cache in the same level that the image
lives. are you doing this in the 1-click image or a normal image?
assuming you can easily see the directory you can just delete it. I'm
sorry i'm not more specific about the error. I'm hoping someone else
chips in with a better description. Last time I debugged one I found
it was an error in the zip protocol; i have no idea why.

cheers,
Mike

2010/4/19 Sean P. DeNigris s...@clipperadams.com:
 Hi, I think this is a common error caused by corrupt mcz files. Can
 you clear your cache and try again?
 Sure, how do I clear the cache?  Also, it was a totally fresh image
 downloaded from the site.

 Sean DeNigris

 
 View this message in context: Re: Error when 'Loading
 11313-Pha-CleaningCompilerTests...'
 Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'


On Apr 19, 2010, at 10:33 PM, Sean P. DeNigris wrote:

  Hi, I think this is a common error caused by corrupt mcz files. Can 
  you clear your cache and try again? 
 Sure, how do I clear the cache?  Also, it was a totally fresh image 
 downloaded from the site. 

on which system are you?
Do you use a one click image

if you use a normal single image not one click, when you download a package it 
is saved in the folder call
package cache that is created on the side of your image.
throw it away.
Normally the file on the server are not corrupted. We test them before 
announcing a new release.


Stef

 
 Sean DeNigris 
 
 View this message in context: Re: Error when 'Loading 
 11313-Pha-CleaningCompilerTests...'
 Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Thrift servers in Pharo (help needed)

2010-04-19 Thread Yoandy Rodríguez Martínez


Hello everyone:

As you may have noticed, Thrift doesn't  generate Smalltalk server code.  
I've added some of the missing classes for server support (ported from  
python implementation) but my Smalltalk skills are not good enough to add  
server-side code into the generator. Is anyone interested?


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

No argument, but I am saying that the Canvas *should* know the resolution of 
the device.  The current division of responsibility between form and canvas is 
not correct.

Bill 


-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr 
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik Sperre 
Johansen
Sent: Monday, April 19, 2010 2:38 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fonts for dummies

  On 19.04.2010 21:10, Schwab,Wilhelm K wrote:
 That will take some (re)reading, but is much appreciated.  The fact 
 that the Canvas is not involved is deeply discouraging: one should not 
 have to edit a class method in order to involve a higher-resolution 
 output device :(
Please note, the output device in your definition, and a Canvas as defined 
in Squeak/Pharo, are two different things.
A canvas does not know the physical dimensions of the display device its raster 
will be displayed on.
Thus using it when rendering will not make any difference, but the 
TextStylespixelsPerInch setting does what you'd like (for FreeType fonts).

Repeated for clarity:
 In essence, if those features are important to you:
 - Use FreeTypeFonts.
 - Set TextStyle pixelsPerInch: to a computed value at startup.
The computed value here meaning: Whatever you somehow manage to find out is 
the correct physical proportion.

Cheers,
Henry

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'



Stéphane Ducasse wrote:
 
 on which system are you?
 Do you use a one click image
 

Pharo image: core 
Pharo core version: PharoCore1.1ALPHA #11312 
Virtual machine used: Squeak 4.2.4beta1U (Mac)

- Sean
-- 
View this message in context: 
http://n4.nabble.com/Error-when-Loading-11313-Pha-CleaningCompilerTests-tp2016295p2016542.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

A good short to mid term goal would be get the flow or responsibility to allow 
kerning to work; then somebody with interest might have pity on us and fill in 
the details.  As things are now, the division between Canvas and Form is not 
correct, so anyone trying to add kerning would have to fight both battles.

BTW, I don't really care about kerning itself; I care that the system design 
does not anticipate it and in fact fights it.

Bill



-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr 
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik Sperre 
Johansen
Sent: Monday, April 19, 2010 2:52 PM
To: pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fonts for dummies

  On 19.04.2010 21:16, Schwab,Wilhelm K wrote:
 I'm not sure how to read it's not the kerning you are looking for.
Read it as if you meant kerning in the sense that the width of a string ~= 
width of each individual character i.e., the ascent/descentKerns in 
StrikeFonts are not used for this.
   What I am trying to discover is how to get the exact pixel size of '0x' 
 and of 'suffix AV' - the latter will potentially involve more kerning than 
 the former.
When rendered by StrikeFonts, no, they will not, since it does not do kerning.
For FreeTypeFonts, #widthOfString:from:to: does exactly what you ask.
It wouldn't be impossible to add kerning to StrikeFonts, but it's a fairly 
major task as you'd need to:
- Update the StrikeFont class to include kerningInfo, and implement
kerningLeft:right: method
- Define font construction methods etc.
- Actually define useful kerning values for fonts in use.
- Update the displayString: primitive to take into account kerning info

Basically, the support is just not there at all at the moment for StrikeFont 
kerning.

Cheers,
Henry

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fonts for dummies

You got me :)  However, setting vs. class-variable is merely an implementation 
detail.  The sad reality is that it is in the wrong place: it is global rather 
than being in Canvas and hence settable each time/place graphics are rendered. 

Bill


-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr 
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik Sperre 
Johansen
Sent: Monday, April 19, 2010 2:43 PM
To: pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fonts for dummies

  On 19.04.2010 21:17, Stéphane Ducasse wrote:
 On Apr 19, 2010, at 9:10 PM, Schwab,Wilhelm K wrote:

 That will take some (re)reading, but is much appreciated.  The fact 
 that the Canvas is not involved is deeply discouraging: one should 
 not have to edit a class method in order to involve a 
 higher-resolution output device :(
 which method?
 open a clear bug entry or request for improvement Stef
It's not a class-method, it's a setting, set by f.ex:
TextStyle pixelsPerInch: 72. (Try changing it to something other than 96 while 
using a FreeType font somewhere, and you can see the text size
changing)

Ideally there'd be code which gathers this value from the system at image 
startup, I'm not aware if such code exists though.
Cheers,
Henry

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] timer ui


Hi,

I am looking for a stopwatch in Pharo. I found LedTimerMorph, but it  
is too limited (only seconds, and no ui manipulation for start/pause).


Do you know if there is another option available?

Cheers,
Doru

--
www.tudorgirba.com

When people care, great things can happen.




___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

2010-04-19 Thread Stephen Taylor


Igor Stasenko wrote:


Fine. Let this mindless crowd go its way. I don't feel a loss.


I do. I would prefer the mindless crowd as you call them to be on our 
side.




 Steve



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] FEATURE: User chooses preferred location for MC directory repositories


http://code.google.com/p/pharo/issues/detail?id=2329

Pharo image: Pharo 1.0

In Monticello Browser, when I click +Repository and select directory,
I'd love to be taken right to the directory where I keep my local
repositories, instead of having to click to the same place over and over.

I changed the following method:
MCDirectoryRepository classmorphicConfigure
^ (UIManager default chooseDirectoryFrom: (FileDirectory on:
'/path/to/my/Repositories')) ifNotNil:
[:directory |
self new directory: directory]

How should I store the default repository directory?  Would anyone else find
this helpful?

Sean DeNigris
-- 
View this message in context: 
http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Issue 2330: BUG: After undo-ing all changes to code shown in OBrowser, it should not be marked as dirty


http://code.google.com/p/pharo/issues/detail?id=2330

Pharo image: Pharo-1.0 #10517
Virtual machine used: Squeak 4.2.4beta1U (Mac)
Class browser used (if applicable):  OBSystemBrowserAdaptor

Steps to reproduce:
1.  In code pane of OBSystemBrowser:
a. make a change to the code
b. undo the change

The code pane is still marked dirty, even though it has now reverted the
original.
-- 
View this message in context: 
http://n4.nabble.com/Issue-2330-BUG-After-undo-ing-all-changes-to-code-shown-in-OBrowser-it-should-not-be-marked-as-dirty-tp2016694p2016694.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!


I subscribe :).

Doru

On 20 Apr 2010, at 00:55, Stephen Taylor wrote:


Igor Stasenko wrote:


Fine. Let this mindless crowd go its way. I don't feel a loss.


I do. I would prefer the mindless crowd as you call them to be on  
our side.




Steve



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


--
www.tudorgirba.com

Beauty is where we see it.




___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Zoomable UI

2010-04-19 Thread Chris Muller

I would think a zoomable UI would be very doable in Croquet..

On Mon, Apr 19, 2010 at 12:32 PM, Igor Stasenko siguc...@gmail.com wrote:
 This is where, i think we should be heading:

 http://ahead.com

 And this is why i think, a graphics frameworks should be vector based,
 not a pixel based one.


 --
 Best regards,
 Igor Stasenko AKA sig.

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Zoomable UI

2010-04-19 Thread David T. Lewis

On Mon, Apr 19, 2010 at 08:32:31PM +0300, Igor Stasenko wrote:
 This is where, i think we should be heading:
 
 http://ahead.com
 
 And this is why i think, a graphics frameworks should be vector based,
 not a pixel based one.

Of course you know of Juan's work in this direction:

  http://www.jvuletich.org/Morphic3/Index.html 

Dave


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] FFI in 1.1

On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse stephane.duca...@inria.fr
 wrote:

 Hi all

 Do we add FFI by default in 1.1?


Noo!!!

I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev
image.

FFI is an EXTERNAL package, NOT core, neither a dev tool.

That's only my opinion.

Cheers

Mariano


 This was the plan so.

 Stef

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo 1.0 - One-click image: cannot handle German Umlauts in Ubuntu file system

And check the bug tracker for already reported issues:

http://code.google.com/p/pharo/issues/

On Thu, Apr 15, 2010 at 10:03 PM, Stéphane Ducasse 
stephane.duca...@inria.fr wrote:

 Hi hannes

 Thanks for the report! You can open a bug entry if you want.

 Stef


 On Apr 15, 2010, at 9:57 PM, Hannes Hirzel wrote:

  Hello
 
  I am sorry for reporting this late. I have been using Squeak for the last
 weeks.
 
  As I saw the announcement of the release I was eager to have look at it.
  The One-click image is neat. Downloading - unzipping and running.
  Loading Seaside was fine.
 
  But a disappointment came when I wanted to file in Monticello files I
  had in a directory on my Ubuntu 9.10 system.
 
  When I wanted to open the directory a UTF8 conversion error came up.
  After I had changed a few umlauts to ASCII it was fine.
 
  Regards
 
  Hannes
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Minor GUI glitch with Pharo 1.0 on Mac

It is already reported...sorry no time to search it in the bug tracker

On Thu, Apr 15, 2010 at 9:22 PM, Stéphane Ducasse stephane.duca...@inria.fr
 wrote:

 this is not a problem but reporting is the first step.
 Now I imagine that we should get a resize window event and react to it.
 On Apr 15, 2010, at 9:19 PM, Lawson English wrote:

  Stéphane Ducasse wrote:
  Simple.
   - Enter a bug entry.
   - Say it in the mailing-list.
   - Send fix.
 
  Consider that Pharo is not our stuff but OUR stuff.
 
  Stef
 
 
 
  Sorry. Definitely did NOT want to seem like a critical non-contributor
 (though I am both, I'm afraid).
 
  At this point, I have no idea how to figure out what is wrong, letalone
 how to fix it.
 
  Lawson
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Stadistics about Pharo 1.0 ?

Hi Marcus/Adrian. Can you tell us more or less stadistics from the Pharo 1.0
release ?   people entering the website, downloading the image, the one
click, PBE, etc ?

thanks

mariano
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Addition to the Success story page

On Thu, Apr 15, 2010 at 10:04 PM, Stéphane Ducasse 
stephane.duca...@inria.fr wrote:

 excellent idea.
 I know that there are other university or engineering schools in argentina.
 I will check that with mariano when he is back


University of Buenos Aires (UBA)
Signature: Algoritmos y programación 3

This is the link:  (go to where it says recursos if you want)
http://materias.fi.uba.ar/7507/

Tomorrow I will give a talk there ;)

Please, also add UTN as Carla said.

Cheers

Mariano


 On Apr 15, 2010, at 9:58 PM, Alexandre Bergel wrote:

  Hi!
 
  Would it be possible to add on the page
 http://www.pharo-project.org/about/success-stories :
  University of Chile in the Universities teaching in Pharo (
 http://www.uchile.cl/), and
  PLEIAD / DCC  in the Research groups using Pharo (http://www.pleiad.cl
 )
 
  Cheers,
  Alexandre
 
  --
  _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
  Alexandre Bergel  http://www.bergel.eu
  ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
 
 
 
 
 
 
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Wish List for Tests

On Fri, Apr 16, 2010 at 11:08 AM, Adrian Lienhard a...@netstyle.ch wrote:

   2. When deleting all test cases using
 
   TestCase allSubclasses do: [:each | each removeFromSystem ]
 



would be great to move all this stuff

unload all test packages
#(Tests CollectionsTests CompilerTests FreeTypeTests GraphicsTests
KernelTests MorphicTests MultilingualTests NetworkTests ToolsTest
'Gofer-Tests')
do: [ :each | (MCPackage named: each) unload ].

unload SUnit
Smalltalk at: #TestCase ifPresent: [ :class |
SystemChangeNotifier uniqueInstance noMoreNotificationsFor: class ].
#(SUnitGUI SUnit) do: [ :each | (MCPackage named: each) unload ].
AppRegistry removeObsolete.
TheWorldMenu removeObsolete.


to a method called unloadAllTestsAndSUnit

so that it can be reused and not only in cleanUpForProduction

cheers

mariano


 I have also Monticello packages changed that are not in test
 packages.
 
 Hope we find the time to clearly separate the tests from
 the core package to clean unload the tests and continue
 the modularization efforts.

 We have that already. I modularized the tests in PharoCore to make them
 cleanly unloadable. Do the following for unloading all tests from PharoCore
 (in ScriptLoader newcleanUpForProduction):

 #(Tests CollectionsTests CompilerTests FreeTypeTests GraphicsTests
 KernelTests MorphicTests MultilingualTests NetworkTests ToolsTest
 'Gofer-Tests') do: [ :each | (MCPackage named: each) unload ].

 If you run this in a Pharo image, it also does not leave any dirty
 packages, but obviously it does not remove the tests from external packages.
 To achieve this, the maintainers of external packages would need to separate
 the tests from the rest of their code. I don't think this is very important,
 though, because unloading tests is most important in PharoCore (that is, to
 strip down an image, you probably don't start from Pharo but PharoCore
 anyway).

 Cheers,
 Adrian
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Minor GUI glitch with Pharo 1.0 on Mac