Re: [Pharo-project] Where does Regex-Core and friends live

[Lukas Renggli]

> I've got a GemSource repository, but I'm actually hoping (haven't run tests
> yet:) that I will be able to use Regex-Core without making any
> GemStone-specific changes ...

That's unlikely, because the code makes quite some absolute stream
positioning like aStream position = 0, aStream position = aStream
size, etc.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

Re: [Pharo-project] Where does Regex-Core and friends live

[Lukas Renggli]

> I am porting the latest Regex to GemStone and in the interest of Pharo
> compatibility, I found Regex-Core and and Regex-Tests-Core in the Pharo
> repository.

The latest code is in .

It is a full port of the latest code from VisualWorks + various
critical bug fixes.

Except for the packaging (which is identical to VisualWorks), it
should be the same as the code in Pharo.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

Re: [Pharo-project] Fuel - a fast object deployment tool

[Adrian Lienhard]

On Dec 8, 2010, at 22:49 , Mariano Martinez Peck wrote:

> On Wed, Dec 8, 2010 at 10:33 PM, Adrian Lienhard  wrote:
> 
>> Hi Martin,
>> 
>> I took some application for which we use image segments to test Fuel
>> 
>> - With Fuel serializing and writing to disk took 330s. File size is 16.1MB
>> - With image segments saving takes 4s and the file size is 2.4MB
>> 
> 
> but how are you using ImageSegment?  just the primitive?  because in order
> to compare it to Fuel, you should write all objects, including
> "outPointers". So you should use #writeForExportOn:  or similar...

yes, this includes outPointers serialized with reference stream and writing to 
disk.

Adrian

BTW, I was just providing the numbers that I gathered when looking at Fuel (to 
see whether that could be interesting for our use case to replace image 
segments). This was not to say that Fuel is not on the right way or anything, 
but I though the numbers would be interesting for Martin because they show a 
real-world use case with a large number of objects. I know that Fuel is in an 
early stage of development and it doesn't (yet?) have a primitive/plugin to 
speed things up.

Re: [Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:

[pharo]

Comment #3 on issue 3391 by stephane.ducasse:  
BlockClosure>>assertWithDescription: sends #logFailure:

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

The first thing I would do is

assertWithDescription: aStringOrABlock
self value ifFalse: [
|value|
value := aStringOrABlock value.
AssertionFailure signal: value]

because logFailure: in anycase write to Transcript

Re: [Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:

[pharo]

Comment #2 on issue 3391 by stephane.ducasse:  
BlockClosure>>assertWithDescription: sends #logFailure:

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

I have no idea what would be logFailure: on Closure and I would like to  
avoid it.

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Peter Hugosson-Miller]

Hehehe, I sure recognize that "pattern", since I've done it myself on occasion: 
copy/paste error when writing accessors. You write the getter first, save it, 
then edit it to create the setter...

--
Cheers,
Peter.

On 9 dec 2010, at 07:35, Stéphane Ducasse  wrote:

> I do not understand
> 
> why 
> 
> model: aModel 
>^model
> 
> such kind of methods are the solution.
> 
> To me it looks like a hack or a design problem
> 
> 
> On Dec 9, 2010, at 2:58 AM, Guillermo Polito wrote:
> 
>> Sorry, It'll fail until Issue 3385 in pharo: TextEditor doest not understand 
>> #model gets fixed. :S
>> 
>> Cheers,
>> Guille
>> 
>> 
>> On Wed, Dec 8, 2010 at 8:48 AM, Marcus Denker  wrote:
>> 
>> On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote:
>> 
>>> 
>>> On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote:
>>> 
 Ok, I've done some fixes to OB and OC, and committed them to 
 PharoTaskForces as a temporary solution.
 
 To load current configuration:
 
 Gofer it squeaksource: 'MetacelloRepository';
  package: 'ConfigurationOfPharo';
  load.
 
 (ConfigurationOfPharo project version: '1.2-beta2') load.
 
 Can Hudson help us in building Dev images?
>>> 
>>> Yes, will set up a build for 1.2 today.
>> 
>> I have set one up that takes 1.2 core, runs updates and then tries to build 
>> dev
>> 
>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/
>> 
>> It is failing right now.
>> 
>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console
>> 
>> 
>> --
>> Marcus Denker  -- http://www.marcusdenker.de
>> INRIA Lille -- Nord Europe. Team RMoD.
>> 
>> 
> 
> 

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

[pharo]

Comment #3 on issue 3385 by stephane.ducasse: TextEditor doest not  
understand #model

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

I do not understand why this is the solution

model: aModel
^model

it looks like a hack

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Stéphane Ducasse]

I do not understand

why 

model: aModel 
^model

such kind of methods are the solution.

To me it looks like a hack or a design problem


On Dec 9, 2010, at 2:58 AM, Guillermo Polito wrote:

> Sorry, It'll fail until Issue 3385 in pharo: TextEditor doest not understand 
> #model gets fixed. :S
> 
> Cheers,
> Guille
> 
> 
> On Wed, Dec 8, 2010 at 8:48 AM, Marcus Denker  wrote:
> 
> On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote:
> 
>> 
>> On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote:
>> 
>>> Ok, I've done some fixes to OB and OC, and committed them to 
>>> PharoTaskForces as a temporary solution.
>>> 
>>> To load current configuration:
>>> 
>>> Gofer it squeaksource: 'MetacelloRepository';
>>>   package: 'ConfigurationOfPharo';
>>>   load.
>>> 
>>> (ConfigurationOfPharo project version: '1.2-beta2') load.
>>> 
>>> Can Hudson help us in building Dev images?
>> 
>> Yes, will set up a build for 1.2 today.
> 
> I have set one up that takes 1.2 core, runs updates and then tries to build 
> dev
> 
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/
> 
> It is failing right now.
> 
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console
> 
> 
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
> 
> 

Re: [Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:

[pharo]

Updates:
Labels: Milestone-1.2

Comment #1 on issue 3391 by stephane.ducasse:  
BlockClosure>>assertWithDescription: sends #logFailure:

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

argh we should fix that!

Re: [Pharo-project] Where does Regex-Core and friends live

[Stéphane Ducasse]

On Dec 9, 2010, at 12:57 AM, Dale Henrichs wrote:

> I am porting the latest Regex to GemStone and in the interest of Pharo 
> compatibility, I found Regex-Core and and Regex-Tests-Core in the Pharo 
> repository.
> 
> In loading Regex-Tests-Core I found some compile errors (doubled '.', a 
> common porting problem) in RxParserTest>>testTranslatingMatchesUsing and 
> RxParserTest>>test, but I don't know where the home repository (other then 
> Pharo) resides, where I could submit my updates.

commit in the inbox


> I've got a GemSource repository, but I'm actually hoping (haven't run tests 
> yet:) that I will be able to use Regex-Core without making any 
> GemStone-specific changes ...

Yes I hope too
> 
> Dale
> 

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

[pharo]

Updates:
Status: fixed
Labels: Milestone-1.2

Comment #2 on issue 3385 by stephane.ducasse: TextEditor doest not  
understand #model

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

(No comment was entered for this change.)

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Stéphane Ducasse]

ok you mean integrated.
Please change the status to fixed else we do not see it when scanning what 
should be merged.

Stef

On Dec 9, 2010, at 2:58 AM, Guillermo Polito wrote:

> Sorry, It'll fail until Issue 3385 in pharo: TextEditor doest not understand 
> #model gets fixed. :S
> 
> Cheers,
> Guille
> 
> 
> On Wed, Dec 8, 2010 at 8:48 AM, Marcus Denker  wrote:
> 
> On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote:
> 
>> 
>> On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote:
>> 
>>> Ok, I've done some fixes to OB and OC, and committed them to 
>>> PharoTaskForces as a temporary solution.
>>> 
>>> To load current configuration:
>>> 
>>> Gofer it squeaksource: 'MetacelloRepository';
>>>   package: 'ConfigurationOfPharo';
>>>   load.
>>> 
>>> (ConfigurationOfPharo project version: '1.2-beta2') load.
>>> 
>>> Can Hudson help us in building Dev images?
>> 
>> Yes, will set up a build for 1.2 today.
> 
> I have set one up that takes 1.2 core, runs updates and then tries to build 
> dev
> 
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/
> 
> It is failing right now.
> 
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console
> 
> 
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
> 
> 

Re: [Pharo-project] Fuel - a fast object deployment tool

[Stéphane Ducasse]

BTW 
when giving feedback consider that the guy doing that is spending a lot of time 
and this will be his master
and that the code was not optimize and that there is no dedicated primitive in 
play. 

So we will see at the end and I was thinking that our little community would be 
much more positive but
we will continue because we believe that there is some value in that.

Stef

Re: [Pharo-project] Fuel - a fast object deployment tool

[Stéphane Ducasse]

It does!
It seems that you did not work in VW2.5 and 3.0 and when parcels arrived 
loading was really a big difference
I do not see why this would not the same with Fuel.

Stef

> The difference is that in Fuel there is no managment for "shared objects".
>> Fuel is not for swapping (there are no stubs/proxies and becomes), and the
>> idea is that you write on a file, ALL (not only those objects that are ONLY
>> accessible by the roots, like in ImageSegment) the objects reachable from
>> user defined roots.
>> 
>> Fuel is similar to ReferenceStream and subclasses, a XML serializer, or any
>> serializers, etc...but MOSTLY, to Parcels. It is very similar to VisualWorks
>> parcel.
>> 
>> Another important thing is that it is binary. The idea is that maybe in a
>> future we have a Monticello that doesn't need a mcz (code) + Compiler, but
>> instead, just load binary code (fuel files). This would be muuuch faster
>> that current Monticello, and even more, for minimal images, we wouldn't need
>> a Compiler.
>> Finally, Fuel is designed (like Parcels) to be very fast at loading time :)
> 
> Well, I doubt if speed is really important, since you're loading everything 
> at most once. And the current tools are really fast IMHO. The following 
> numbers are from Squeak:
> [ Compiler recompileAll ] timeToRun. 29083.
> CompiledMethod allInstances size. 60701.
> [ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun. 1133.
> So the compiler is compiling 2087 methods per second on average. You can load 
> 53575 methods per second from a file on average. If it's zipped, than it may 
> be a bit slower, say a factor of 2-3x slowdown. So you can still load and 
> compile more than 1800 methods per second. I guess thats fast enough.
> 
> Even if Fuel can be 10x faster, it doesn't really make a difference IMHO.
> 
> 
> Levente
> 
>> 
>> Cheers
>> 
>> Mariano
>> 
>> 
>> 
>> 
>>> It looks exciting!
>>> 
>>> Alexandre
>>> 
>>> 
 
> 
> Alexandre
> 
> 
> On 8 Dec 2010, at 13:50, Martin Dias wrote:
> 
>> Hi all
>> 
>> Last months I and Tristan have been working on Fuel project, an object
>> binary serialization tool. The idea is that objects are much more
>> times loaded than stored, therefore it is worth to spend time while
>> storing in order to have faster loading and user experience. We
>> present an implementation of a pickle format that is based on
>> clustering similar objects.
>> 
>> There is a summary of the project below, but more complete information
>> is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
>> 
>> The implementation still needs a lot of work to be really useful,
>> optimizations should be done, but we'll be glad to get feedback of the
>> community.
>> 
>> 
>> = Pickle format =
>> 
>> The pickle format and the serialization algorithm main idea, is
>> explained in this slides:
>> 
>> http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
>> 
>> 
>> = Current features =
>> 
>> - Class shape changing (when a variable has been added, or removed, or
>> its index changed)
>> - Serialize most of the basic objects.
>> - Serialize (almost) any CompiledMethod
>> - Detection of global or class variables
>> - Support for cyclic object graphs
>> - Tests
>> 
>> 
>> = Next steps =
>> 
>> - Improve version checking.
>> - Optimize performance.
>> - Serialize more kinds of objects:
>> -- Class with its complete description.
>> -- Method contexts
>> -- Active block closures
>> -- Continuation
>> - Some improvements for the user:
>> -- pre and post actions to be executed.
>> -- easily say 'this object is singleton'.
>> - Partial loading of a stored graph.
>> - Fast statistics/brief info extraction of a stored graph.
>> - ConfigurationOfFuel.
>> - Be able to deploy materialization behavior only (independent from
>> the serialization behavior)
>> 
>> 
>> = Download =
>> 
>> In a Pharo 1.1 or 1.1.1 evaluate:
>> 
>> Gofer new
>>squeaksource: 'Fuel';
>>version: 'Fuel-MartinDias.74';
>>version: 'FuelBenchmarks-MartinDias.4';
>>load.
>> 
>> 
>> = Benchmarks =
>> 
>> You can run benchmarks executing this line (results in Transcript):
>> 
>> FLBenchmarks newBasic run.
>> 
>> 
>> Thank you!
>> Martin Dias
>> 
> 
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 
> 
> 
 
 
>>> 
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 

Re: [Pharo-project] Morph wont delete in pharo, cant select it...

[Joseph T. Bore]

This worked great, thanks. 

I have an osx machine running on non apple hardware where the solution was less 
obvious but on my Mac it worked great, thanks everyone!

jb

On Dec 8, 2010, at 3:01 PM, Stéphane Ducasse  wrote:

> don't cry...
> 
> Try alt + shift + click to bring the halos.
> 
> We did it like that else the halos gets really in your way all the time.
> 
> Stef
> 
> 
> On Dec 8, 2010, at 8:55 PM, Joseph T. Bore wrote:
> 
>> 
>> ive had my fingers in knots over here trying what seems like every 
>> control/alt/shift left button/right button combination.  
>> 
>> control is usually the way to get the alternate click on a mac with one 
>> button but this is the third button. im having no luck.
>> 
>> 
>> 
>> 
>> On Dec 8, 2010, at 2:52 PM, Gary Chambers wrote:
>> 
>>> Not sure, having no Mac (only iPad etc...)
>>> Try opt-shift clicks perhaps?
>>> Shift is a definite component of the magic combination!
>>> 
>>> Regards, Gary
>>> 
>>> - Original Message - From: "Joseph T. Bore" 
>>> To: 
>>> Sent: Wednesday, December 08, 2010 7:36 PM
>>> Subject: Re: [Pharo-project] Morph wont delete in pharo, cant select it...
>>> 
>>> 
>>> 
>>> anyway to get that on a mac with a 2 button mouse?  im on a laptop, i have 
>>> 2 buttons, but not three.  is there some preference that can be set to give 
>>> me access to that?
>>> 
>>> 
>>> On Dec 8, 2010, at 2:28 PM, Gary Chambers wrote:
>>> 
 Try shift-mid-click on morph for halo.
 
 Regards, Gary
 
 - Original Message - From: "Joseph T. Bore" 
 To: 
 Sent: Wednesday, December 08, 2010 7:16 PM
 Subject: [Pharo-project] Morph wont delete in pharo, cant select it...
 
 
 
 am i doing something obviously wrong?:
 
 i have downloaded Pharo 1.1.1 (single click) for Mac OSX
 
 bring up the image then:
 
 Morph new openInWorld, do it.  (get a nice blue square, perfect)
 
 click to pick it up and move it around, all is well
 
 control click, brings up menu for morph
 
 here is where the problems start
 
 delete menu option, Blue square wont go away...
 
 add halos menu option gives halos but they are on the PasteupMorph (the 
 desktop i think).
 
 i cant find any way to get rid of this morph, will i have a blue friend 
 forever?
 
 im sure im doing something obviously wrong, just dont know what it is...
 
 
 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-project] Global shortcut keys in Pharo

[Tony Fleig]

A follow-up:

I scanned the email threads mentioned in this thread.

I tried to use Keymapper and it seemed way too complicated for the
simple things I wanted to do. It wasn't obvious at all to me how to
proceed once I had the GUI displayed and I encountered numerous errors
while exploring it. After perusing the code a little, it seemed much
more invasive than what I had in mind -- extensions and overrides in
numerous classes. It seems to be a general approach for solving
keystroke mapping not only at the global level, but in
application-specific cases as well.

I have placed my own GlobalKeys package on SqueakSource
(http://www.squeaksource.com/GlobalKeys) It is much smaller and less
ambitious than Keymapper, it only works on Pharo, and it is much less
capable, but at least in my environment it does what I need without a
lot of complication. Maybe someone else will find it useful as well.

One of the joys of Smalltalk: if you don't like the way something
works, change it or write your own.

Regards,
TF

On Fri, Dec 3, 2010 at 8:19 PM, Tony Fleig  wrote:
> I find myself wanting global keyboard shortcuts for such things as
> invoking an external browser, switching focus between windows, opening
> new tool windows, executing various World menu options, executing my
> own scripts, etc.
>
> After working for years in corporations doing Windows-based
> development in Microsoft Visual Studio, I find the necessity of
> constantly reaching for the mouse in Pharo to be cumbersome and
> unproductive.
>
> I was able to add some shortcut keys to invoke commands that I
> prepared by sending messages like this:
>
>    World respondToCommand: $l bySending: #startExternalWebBrowser to:
> TFCommands.
>
> However, this only works when no window has the keyboard focus.
>
> I followed the keystroke handling path in the debugger and I think I
> can probably find a place to hook in some special handling for my
> globally-accessible keystrokes.
>
> My questions are:
>
> 1. Has somebody already done this?
>
> 2. Is there a "standard" or "best practice" way of accomplishing this?
>
> Regards,
> TF
>

Re: [Pharo-project] Where does Regex-Core and friends live

[Alexandre Bergel]

hi Dale!

I do not know about your need. But personally, if I have to deal with non 
trivial parsing, I will use PetitParser. 
Lukas made a tutorial last week and I am convinced.

Cheers,
Alexandre


On 8 Dec 2010, at 20:57, Dale Henrichs wrote:

> I am porting the latest Regex to GemStone and in the interest of Pharo 
> compatibility, I found Regex-Core and and Regex-Tests-Core in the Pharo 
> repository.
> 
> In loading Regex-Tests-Core I found some compile errors (doubled '.', a 
> common porting problem) in RxParserTest>>testTranslatingMatchesUsing and 
> RxParserTest>>test, but I don't know where the home repository (other then 
> Pharo) resides, where I could submit my updates.
> 
> I've got a GemSource repository, but I'm actually hoping (haven't run tests 
> yet:) that I will be able to use Regex-Core without making any 
> GemStone-specific changes ...
> 
> Dale
> 

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

Re: [Pharo-project] Finder issue?

[Francisco Ortiz Peñaloza]

Ben,

this could somewhat related to
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg36339.htmlright?

Cheers,
Francisco

On Wed, Dec 8, 2010 at 7:56 PM, Benjamin <
benjamin.vanryseghem.ph...@gmail.com> wrote:

>
> On Dec 8, 2010, at 10:45 PM, Francisco Ortiz Peñaloza wrote:
>
> Great! Didn't know that but what about AppRegistry? I didn't see much of
> it, don't know if its an old idea or have a bad implementation but would it
> be better to use some dynamic binding mechanism so given any other day
> someone could change the editor globally like *MorphicTextEditor default *
> works.
>
> hmm i think i'm missing something
>
>
> AppRegistry was a good idea ages ago, but I do not know if it could really
> be useful now ...
>
> I'll take a look at that ^^
>
>
> Ben
>
>
>
> Thanks,
> Francisco
>
> On Wed, Dec 8, 2010 at 7:00 PM, Benjamin <
> benjamin.vanryseghem.ph...@gmail.com> wrote:
>
>>
>> On Dec 8, 2010, at 8:37 PM, Francisco Ortiz Peñaloza wrote:
>>
>> Hi,
>>
>> after loading last Shout on PharoCore the new Finder isn't working
>> properly. Let's see
>>
>> PluggableShoutMorph>>initialize registers Shout in AppRegistry as the
>> default MorphicTextEditor but FinderUI>>buildSourceTextArea uses a
>> PluggableTextMorph.
>>
>> I think it should be using the more dinamic *MorphicTextEditor 
>> default*insted of the hardcoded PluggableTextMorph. Am i right?
>>
>>
>> In 1.2, it was panned that PluggableTextMorph and PluggableShoutMorph
>> should been merged. In fact, I've posted a fix to allow PluggableTextMorph
>> to handle text styling, this way Shout isn't needed anymore :)
>>
>>
>> Thank you for your review,
>>
>>
>> Ben
>>
>>
>
>

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Guillermo Polito]

Sorry, It'll fail until *Issue 3385 in pharo: TextEditor doest not
understand #model* gets fixed. :S

Cheers,
Guille


On Wed, Dec 8, 2010 at 8:48 AM, Marcus Denker wrote:

>
> On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote:
>
>
> On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote:
>
> Ok, I've done some fixes to OB and OC, and committed them to
> PharoTaskForces as a temporary solution.
>
> To load current configuration:
>
> Gofer it squeaksource: 'MetacelloRepository';
>   package: 'ConfigurationOfPharo';
>   load.
>
> (ConfigurationOfPharo project version: '1.2-beta2') load.
>
> Can Hudson help us in building Dev images?
>
>
> Yes, will set up a build for 1.2 today.
>
>
> I have set one up that takes 1.2 core, runs updates and then tries to build
> dev
>
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/
>
> It is failing right now.
>
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console
>
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

[Guillermo Polito]

I agree with everyone in that OCompletion makes non sense with TextEditor.

How can we make it work with SmalltalkEditor and avoid the case in the
screenshot of Francisco?

I can help you if you need it :).

Cheers,
Guille

2010/12/8 Levente Uzonyi 

> On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
>
>  Levente,
>>
>> that's weird, i'm sending you a screenshot i'm running PharoCore 12271
>> with Ocompletion-ul.88 loaded
>>
>
> Right, I forgot to change the ToolSet to ECToolSet. Now I see the problem.
>
>
>
>> I really like how you clear the way with these two questions,
>> - should OCompletion be used in that panel?
>> - should that panel use TextEditor instead of SmalltalkEditor?
>>
>> Using OCompletion is ok i think, in another email i said that having two
>> way
>> autocompletion with the TextEditor element and the recent WHATEVER used
>> list
>> above dont make sense to me, but some argue that they use their mouse to
>> go
>> to a recently used class.
>>
>> i think the finder window should be minimal, just the input text element
>> -no
>> recent used list- and have autocompletion (ie. web autocompletion). As web
>> users we see that a lot, i will not miss the recent WHATEVER list.
>>
>
> A big +1 (note that I'm not a Pharo user). If there's need for the recent
> classes, then it should be available via a different menu item + shortcut.
>
>
>
>> On your second question, imho we're trying to find a Smalltalk class or
>> Smalltalk WHATEVER, could be better to have a SmalltalkEditor instance
>> instead of TextEditor one.
>>
>
> If the idea is to keep this tool this way (recent classes list + no
> autocompleter), then I'd probably change it to SmalltalkEditor. But adding
> the method #model to TextMorph will "fix" this problem anyway.
>
>
> Levente
>
>
>
>> Cheers,
>> Francisco
>>
>> [image: PharoScreenshot.1.png]
>>
>> On Wed, Dec 8, 2010 at 4:20 AM, Alain Plantec 
>> wrote:
>>
>>  I agree with Levente. The basic completion (cmd-q) is also only usable
>>> with
>>> a SmalltalkEditor.
>>> Cheers
>>> Alain
>>>
>>> Le 08/12/2010 03:58, Levente Uzonyi a écrit :
>>>
>>>  On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
>>>

  So Levente you're saying that given the following use case you musn't
 add

> #model to TextEditor but change TextEditor collaboration with an
> instance
> of
> SmalltalkEditor
>
> OCompletion works well to edit code in the system browser as is, the
> DNU
> occurs when as an example you do a class find (Cmd+f) on SystemBrowser
> and
> you start typing on that "Class name or fragment" window looking for
> something.
>
>
 Adding the accessor is fine of course, it may be useful for other things
 too. I'm saying that OCompletion is intended to work in places where
 code
 completion is necessary and those places are usually SmalltalkEditors.
 There
 are two things to think about:
 - should OCompletion be used in that panel?
 - should that panel use TextEditor instead of SmalltalkEditor?

 Btw using the latest version of PharoCore (12271) I can't reproduce the
 error in the way you described it.


 Levente


  Cheers,
> Francisco
>
> On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi  wrote:
>
>  On Tue, 7 Dec 2010, ph...@googlecode.com wrote:
>
>>
>>  Status: Accepted
>>
>>  Owner: guillermopolito
>>>
>>> New issue 3385 by guillermopolito: TextEditor doest not understand
>>> #model
>>> http://code.google.com/p/pharo/issues/detail?id=3385
>>>
>>> The accessor should be added to load last version of OCompletion in
>>> Core
>>> 1.2
>>>
>>>
>>>
>>>  OCompletion shouldn't be used in a TextEditor. OCompletion is for
>>>
>> Smalltalk
>> code completion, while TextEditor is intended to be a text editor (ask
>> Juan). That's why OCompletion adds the model accessor to
>> SmalltalkEditor
>> and
>> not to TextEditor.
>>
>>
>> Levente
>>
>>
>>
>>
>


>>>
>>>

[Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:

[pharo]

Status: Accepted
Owner: da...@teleport.com

New issue 3391 by da...@teleport.com: BlockClosure>>assertWithDescription:  
sends #logFailure:

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

In a PharoCore image (Pharo1.1.1 #11414 or Pharo1.2a #12271) the only  
sender of #assertWithDescription: is RxMatcher>>split: ... which wouldn't  
be that bad, except that BlockClosure>>assertWithDescription: sends  
#logFailure: which is only implemented in TestCase 


S, it appears that assertWithDescription: should only be sent from  
instances of TestCase (and send removed from RxMatcher>>split:) or the send  
of #logFailure: removed from BlockClosure>>assertWithDescription: ...


Found this on in GemStone testing while trying to figure out a test case  
that would trigger a failure of #assertWithDescription:, which BTW, I  
couldn't do  so the #assertWithDescription: is probably unnecessary (or  
we need a test case to trigger the assertion)...

[Pharo-project] Where does Regex-Core and friends live

[Dale Henrichs]

I am porting the latest Regex to GemStone and in the interest of Pharo 
compatibility, I found Regex-Core and and Regex-Tests-Core in the Pharo 
repository.


In loading Regex-Tests-Core I found some compile errors (doubled '.', a 
common porting problem) in RxParserTest>>testTranslatingMatchesUsing and 
RxParserTest>>test, but I don't know where the home repository (other 
then Pharo) resides, where I could submit my updates.


I've got a GemSource repository, but I'm actually hoping (haven't run 
tests yet:) that I will be able to use Regex-Core without making any 
GemStone-specific changes ...


Dale

Re: [Pharo-project] Fuel - a fast object deployment tool

[Levente Uzonyi]

On Wed, 8 Dec 2010, Adrian Lienhard wrote:



On Dec 8, 2010, at 22:33 , Levente Uzonyi wrote:


On Wed, 8 Dec 2010, Mariano Martinez Peck wrote:

Well, I doubt if speed is really important, since you're loading everything at 
most once. And the current tools are really fast IMHO. The following numbers 
are from Squeak:
[ Compiler recompileAll ] timeToRun. 29083.
CompiledMethod allInstances size. 60701.
[ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun. 1133.
So the compiler is compiling 2087 methods per second on average. You can load 
53575 methods per second from a file on average. If it's zipped, than it may be 
a bit slower, say a factor of 2-3x slowdown. So you can still load and compile 
more than 1800 methods per second. I guess thats fast enough.

Even if Fuel can be 10x faster, it doesn't really make a difference IMHO.


It would be interesting to thoroughly profile MC to figure where it spends all 
its time (with large projects it gets very very slow, like several minutes to 
just show the merge diffs between two branches).


I guess those days are over when MC spends minutes doing this, it's at 
most a few seconds for large packages. The 1.5MB Morphic package of Squeak 
can be compared to another really old version (changes) in 3 seconds. 
According to MessageTally 50% of the time is spend in getting the 
timeStamp for the methods.



Levente



Adrian

Re: [Pharo-project] Finder issue?

[Benjamin]

On Dec 8, 2010, at 10:45 PM, Francisco Ortiz Peñaloza wrote:

Great! Didn't know that but what about AppRegistry? I didn't see  
much of it, don't know if its an old idea or have a bad  
implementation but would it be better to use some dynamic binding  
mechanism so given any other day someone could change the editor  
globally like MorphicTextEditor default works.


hmm i think i'm missing something


AppRegistry was a good idea ages ago, but I do not know if it could  
really be useful now ...


I'll take a look at that ^^


Ben




Thanks,
Francisco

On Wed, Dec 8, 2010 at 7:00 PM, Benjamin > wrote:


On Dec 8, 2010, at 8:37 PM, Francisco Ortiz Peñaloza wrote:


Hi,

after loading last Shout on PharoCore the new Finder isn't working  
properly. Let's see


PluggableShoutMorph>>initialize registers Shout in AppRegistry as  
the default MorphicTextEditor but FinderUI>>buildSourceTextArea  
uses a PluggableTextMorph.


I think it should be using the more dinamic MorphicTextEditor  
default insted of the hardcoded PluggableTextMorph. Am i right?


In 1.2, it was panned that PluggableTextMorph and  
PluggableShoutMorph should been merged. In fact, I've posted a fix  
to allow PluggableTextMorph to handle text styling, this way Shout  
isn't needed anymore :)



Thank you for your review,


Ben

Re: [Pharo-project] Fuel - a fast object deployment tool

[Mariano Martinez Peck]

On Wed, Dec 8, 2010 at 10:38 PM, Adrian Lienhard  wrote:

>
> On Dec 8, 2010, at 22:33 , Levente Uzonyi wrote:
>
> > On Wed, 8 Dec 2010, Mariano Martinez Peck wrote:
> >
> > Well, I doubt if speed is really important, since you're loading
> everything at most once. And the current tools are really fast IMHO. The
> following numbers are from Squeak:
> > [ Compiler recompileAll ] timeToRun. 29083.
> > CompiledMethod allInstances size. 60701.
> > [ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun.
> 1133.
> > So the compiler is compiling 2087 methods per second on average. You can
> load 53575 methods per second from a file on average. If it's zipped, than
> it may be a bit slower, say a factor of 2-3x slowdown. So you can still load
> and compile more than 1800 methods per second. I guess thats fast enough.
> >
> > Even if Fuel can be 10x faster, it doesn't really make a difference IMHO.
>
> It would be interesting to thoroughly profile MC to figure where it spends
> all its time (with large projects it gets very very slow, like several
> minutes to just show the merge diffs between two branches).
>
>
>
Exactly. That's why I was suggesting that maybe with a fast binary
serializer this can be much faster.

Re: [Pharo-project] Fuel - a fast object deployment tool

[Mariano Martinez Peck]

On Wed, Dec 8, 2010 at 10:33 PM, Adrian Lienhard  wrote:

> Hi Martin,
>
> I took some application for which we use image segments to test Fuel
>
> - With Fuel serializing and writing to disk took 330s. File size is 16.1MB
> - With image segments saving takes 4s and the file size is 2.4MB
>

but how are you using ImageSegment?  just the primitive?  because in order
to compare it to Fuel, you should write all objects, including
"outPointers". So you should use #writeForExportOn:  or similar...

funny it is only 4s in IS, since it has to do a #become, a full GC mark
phase, etc...


>
> - When loading, I got a low space warning because the primitive
> newMethod:header: failed.
> - Loading with image segments takes 11 seconds
>
> I wonder what your rational is for "objects are much more times loaded than
> stored".


That's Fuel purpose. And it is useful for version systems, where you may
commit once (a specfic version for example), but load hundred of times.


> In our case its exactly the other way round. We store very often (like
> every couple of minutes if there are changes), but only load when we restart
> an image (this may be weeks).
>
>
So I guess Fuel is not the best approach for you :)


> HTH,
> Adrian
>
> On Dec 8, 2010, at 17:50 , Martin Dias wrote:
>
> > Hi all
> >
> > Last months I and Tristan have been working on Fuel project, an object
> > binary serialization tool. The idea is that objects are much more
> > times loaded than stored, therefore it is worth to spend time while
> > storing in order to have faster loading and user experience. We
> > present an implementation of a pickle format that is based on
> > clustering similar objects.
> >
> > There is a summary of the project below, but more complete information
> > is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
> >
> > The implementation still needs a lot of work to be really useful,
> > optimizations should be done, but we'll be glad to get feedback of the
> > community.
> >
> >
> > = Pickle format =
> >
> > The pickle format and the serialization algorithm main idea, is
> > explained in this slides:
> >
> > http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
> >
> >
> > = Current features =
> >
> > - Class shape changing (when a variable has been added, or removed, or
> > its index changed)
> > - Serialize most of the basic objects.
> > - Serialize (almost) any CompiledMethod
> > - Detection of global or class variables
> > - Support for cyclic object graphs
> > - Tests
> >
> >
> > = Next steps =
> >
> > - Improve version checking.
> > - Optimize performance.
> > - Serialize more kinds of objects:
> > -- Class with its complete description.
> > -- Method contexts
> > -- Active block closures
> > -- Continuation
> > - Some improvements for the user:
> > -- pre and post actions to be executed.
> > -- easily say 'this object is singleton'.
> > - Partial loading of a stored graph.
> > - Fast statistics/brief info extraction of a stored graph.
> > - ConfigurationOfFuel.
> > - Be able to deploy materialization behavior only (independent from
> > the serialization behavior)
> >
> >
> > = Download =
> >
> > In a Pharo 1.1 or 1.1.1 evaluate:
> >
> > Gofer new
> >   squeaksource: 'Fuel';
> >   version: 'Fuel-MartinDias.74';
> >   version: 'FuelBenchmarks-MartinDias.4';
> >   load.
> >
> >
> > = Benchmarks =
> >
> > You can run benchmarks executing this line (results in Transcript):
> >
> > FLBenchmarks newBasic run.
> >
> >
> > Thank you!
> > Martin Dias
> >
>
>
>

Re: [Pharo-project] Finder issue?

[Francisco Ortiz Peñaloza]

Great! Didn't know that but what about AppRegistry? I didn't see much of it,
don't know if its an old idea or have a bad implementation but would it be
better to use some dynamic binding mechanism so given any other day someone
could change the editor globally like *MorphicTextEditor default *works.

hmm i think i'm missing something

Thanks,
Francisco

On Wed, Dec 8, 2010 at 7:00 PM, Benjamin <
benjamin.vanryseghem.ph...@gmail.com> wrote:

>
> On Dec 8, 2010, at 8:37 PM, Francisco Ortiz Peñaloza wrote:
>
> Hi,
>
> after loading last Shout on PharoCore the new Finder isn't working
> properly. Let's see
>
> PluggableShoutMorph>>initialize registers Shout in AppRegistry as the
> default MorphicTextEditor but FinderUI>>buildSourceTextArea uses a
> PluggableTextMorph.
>
> I think it should be using the more dinamic *MorphicTextEditor default*insted 
> of the hardcoded PluggableTextMorph. Am i right?
>
>
> In 1.2, it was panned that PluggableTextMorph and PluggableShoutMorph
> should been merged. In fact, I've posted a fix to allow PluggableTextMorph
> to handle text styling, this way Shout isn't needed anymore :)
>
>
> Thank you for your review,
>
>
> Ben
>
>

Re: [Pharo-project] Fuel - a fast object deployment tool

[Adrian Lienhard]

On Dec 8, 2010, at 22:33 , Levente Uzonyi wrote:

> On Wed, 8 Dec 2010, Mariano Martinez Peck wrote:
> 
> Well, I doubt if speed is really important, since you're loading everything 
> at most once. And the current tools are really fast IMHO. The following 
> numbers are from Squeak:
> [ Compiler recompileAll ] timeToRun. 29083.
> CompiledMethod allInstances size. 60701.
> [ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun. 1133.
> So the compiler is compiling 2087 methods per second on average. You can load 
> 53575 methods per second from a file on average. If it's zipped, than it may 
> be a bit slower, say a factor of 2-3x slowdown. So you can still load and 
> compile more than 1800 methods per second. I guess thats fast enough.
> 
> Even if Fuel can be 10x faster, it doesn't really make a difference IMHO.

It would be interesting to thoroughly profile MC to figure where it spends all 
its time (with large projects it gets very very slow, like several minutes to 
just show the merge diffs between two branches).

Adrian

Re: [Pharo-project] Fuel - a fast object deployment tool

[Adrian Lienhard]

Hi Martin,

I took some application for which we use image segments to test Fuel

- With Fuel serializing and writing to disk took 330s. File size is 16.1MB
- With image segments saving takes 4s and the file size is 2.4MB

- When loading, I got a low space warning because the primitive 
newMethod:header: failed. 
- Loading with image segments takes 11 seconds

I wonder what your rational is for "objects are much more times loaded than 
stored". In our case its exactly the other way round. We store very often (like 
every couple of minutes if there are changes), but only load when we restart an 
image (this may be weeks).

HTH,
Adrian

On Dec 8, 2010, at 17:50 , Martin Dias wrote:

> Hi all
> 
> Last months I and Tristan have been working on Fuel project, an object
> binary serialization tool. The idea is that objects are much more
> times loaded than stored, therefore it is worth to spend time while
> storing in order to have faster loading and user experience. We
> present an implementation of a pickle format that is based on
> clustering similar objects.
> 
> There is a summary of the project below, but more complete information
> is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
> 
> The implementation still needs a lot of work to be really useful,
> optimizations should be done, but we'll be glad to get feedback of the
> community.
> 
> 
> = Pickle format =
> 
> The pickle format and the serialization algorithm main idea, is
> explained in this slides:
> 
> http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
> 
> 
> = Current features =
> 
> - Class shape changing (when a variable has been added, or removed, or
> its index changed)
> - Serialize most of the basic objects.
> - Serialize (almost) any CompiledMethod
> - Detection of global or class variables
> - Support for cyclic object graphs
> - Tests
> 
> 
> = Next steps =
> 
> - Improve version checking.
> - Optimize performance.
> - Serialize more kinds of objects:
> -- Class with its complete description.
> -- Method contexts
> -- Active block closures
> -- Continuation
> - Some improvements for the user:
> -- pre and post actions to be executed.
> -- easily say 'this object is singleton'.
> - Partial loading of a stored graph.
> - Fast statistics/brief info extraction of a stored graph.
> - ConfigurationOfFuel.
> - Be able to deploy materialization behavior only (independent from
> the serialization behavior)
> 
> 
> = Download =
> 
> In a Pharo 1.1 or 1.1.1 evaluate:
> 
> Gofer new
>   squeaksource: 'Fuel';
>   version: 'Fuel-MartinDias.74';
>   version: 'FuelBenchmarks-MartinDias.4';
>   load.
> 
> 
> = Benchmarks =
> 
> You can run benchmarks executing this line (results in Transcript):
> 
> FLBenchmarks newBasic run.
> 
> 
> Thank you!
> Martin Dias
> 

Re: [Pharo-project] Fuel - a fast object deployment tool

[Levente Uzonyi]

On Wed, 8 Dec 2010, Mariano Martinez Peck wrote:


On Wed, Dec 8, 2010 at 9:05 PM, Alexandre Bergel wrote:


It look cool!
Is this a better ImageSegment?


there is no VM code implied and you do not get all the problems of

imageSegment.

You should ask is it better than SmartRefStreams.
Yes
Now the code has not been optimized


Ah ok! How to deal with stubs is the difference with ImageSegment then.



The difference is that in Fuel there is no managment for "shared objects".
Fuel is not for swapping (there are no stubs/proxies and becomes), and the
idea is that you write on a file, ALL (not only those objects that are ONLY
accessible by the roots, like in ImageSegment) the objects reachable from
user defined roots.

Fuel is similar to ReferenceStream and subclasses, a XML serializer, or any
serializers, etc...but MOSTLY, to Parcels. It is very similar to VisualWorks
parcel.

Another important thing is that it is binary. The idea is that maybe in a
future we have a Monticello that doesn't need a mcz (code) + Compiler, but
instead, just load binary code (fuel files). This would be muuuch faster
that current Monticello, and even more, for minimal images, we wouldn't need
a Compiler.
Finally, Fuel is designed (like Parcels) to be very fast at loading time :)


Well, I doubt if speed is really important, since you're loading 
everything at most once. And the current tools are really fast IMHO. The 
following numbers are from Squeak:

[ Compiler recompileAll ] timeToRun. 29083.
CompiledMethod allInstances size. 60701.
[ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun. 1133.
So the compiler is compiling 2087 methods per second on average. You can 
load 53575 methods per second from a file on average. If it's zipped, than 
it may be a bit slower, say a factor of 2-3x slowdown. So you can still 
load and compile more than 1800 methods per second. I guess thats fast 
enough.


Even if Fuel can be 10x faster, it doesn't really make a difference IMHO.


Levente



Cheers

Mariano





It looks exciting!

Alexandre






Alexandre


On 8 Dec 2010, at 13:50, Martin Dias wrote:


Hi all

Last months I and Tristan have been working on Fuel project, an object
binary serialization tool. The idea is that objects are much more
times loaded than stored, therefore it is worth to spend time while
storing in order to have faster loading and user experience. We
present an implementation of a pickle format that is based on
clustering similar objects.

There is a summary of the project below, but more complete information
is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel

The implementation still needs a lot of work to be really useful,
optimizations should be done, but we'll be glad to get feedback of the
community.


= Pickle format =

The pickle format and the serialization algorithm main idea, is
explained in this slides:

http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example


= Current features =

- Class shape changing (when a variable has been added, or removed, or
its index changed)
- Serialize most of the basic objects.
- Serialize (almost) any CompiledMethod
- Detection of global or class variables
- Support for cyclic object graphs
- Tests


= Next steps =

- Improve version checking.
- Optimize performance.
- Serialize more kinds of objects:
-- Class with its complete description.
-- Method contexts
-- Active block closures
-- Continuation
- Some improvements for the user:
-- pre and post actions to be executed.
-- easily say 'this object is singleton'.
- Partial loading of a stored graph.
- Fast statistics/brief info extraction of a stored graph.
- ConfigurationOfFuel.
- Be able to deploy materialization behavior only (independent from
the serialization behavior)


= Download =

In a Pharo 1.1 or 1.1.1 evaluate:

Gofer new
squeaksource: 'Fuel';
version: 'Fuel-MartinDias.74';
version: 'FuelBenchmarks-MartinDias.4';
load.


= Benchmarks =

You can run benchmarks executing this line (results in Transcript):

FLBenchmarks newBasic run.


Thank you!
Martin Dias



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











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

[Pharo-project] Issue 3389 in pharo: should add SimpleMorphic in core

[pharo]

Status: Fixed
Owner: stephane.ducasse
Labels: Milestone-1.2

New issue 3389 by stephane.ducasse: should add SimpleMorphic in core
http://code.google.com/p/pharo/issues/detail?id=3389

so that it does not rot.
Now I pubished it into PharoTaskForces

Re: [Pharo-project] Finder issue?

[Benjamin]

On Dec 8, 2010, at 8:37 PM, Francisco Ortiz Peñaloza wrote:


Hi,

after loading last Shout on PharoCore the new Finder isn't working  
properly. Let's see


PluggableShoutMorph>>initialize registers Shout in AppRegistry as  
the default MorphicTextEditor but FinderUI>>buildSourceTextArea uses  
a PluggableTextMorph.


I think it should be using the more dinamic MorphicTextEditor  
default insted of the hardcoded PluggableTextMorph. Am i right?


In 1.2, it was panned that PluggableTextMorph and PluggableShoutMorph  
should been merged. In fact, I've posted a fix to allow  
PluggableTextMorph to handle text styling, this way Shout isn't needed  
anymore :)



Thank you for your review,


Ben

[Pharo-project] Issue 3390 in pharo: should add SimpleMorphic in core

[pharo]

Status: Fixed
Owner: stephane.ducasse
Labels: Milestone-1.2

New issue 3390 by stephane.ducasse: should add SimpleMorphic in core
http://code.google.com/p/pharo/issues/detail?id=3390

so that it does not rot.
Now I pubished it into PharoTaskForces

[Pharo-project] ODBC, loadFFI and friends!

[Torsten Bergmann]

Did you see

http://www.pharocasts.com/2010/12/access-database-through-odbc.html

Bye
T. 
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

Re: [Pharo-project] Fuel - a fast object deployment tool

[Mariano Martinez Peck]

On Wed, Dec 8, 2010 at 9:05 PM, Alexandre Bergel wrote:

> >> It look cool!
> >> Is this a better ImageSegment?
> >
> > there is no VM code implied and you do not get all the problems of
> imageSegment.
> > You should ask is it better than SmartRefStreams.
> > Yes
> > Now the code has not been optimized
>
> Ah ok! How to deal with stubs is the difference with ImageSegment then.
>
>
The difference is that in Fuel there is no managment for "shared objects".
Fuel is not for swapping (there are no stubs/proxies and becomes), and the
idea is that you write on a file, ALL (not only those objects that are ONLY
accessible by the roots, like in ImageSegment) the objects reachable from
user defined roots.

Fuel is similar to ReferenceStream and subclasses, a XML serializer, or any
serializers, etc...but MOSTLY, to Parcels. It is very similar to VisualWorks
parcel.

Another important thing is that it is binary. The idea is that maybe in a
future we have a Monticello that doesn't need a mcz (code) + Compiler, but
instead, just load binary code (fuel files). This would be muuuch faster
that current Monticello, and even more, for minimal images, we wouldn't need
a Compiler.
Finally, Fuel is designed (like Parcels) to be very fast at loading time :)

Cheers

Mariano




> It looks exciting!
>
> Alexandre
>
>
> >
> >>
> >> Alexandre
> >>
> >>
> >> On 8 Dec 2010, at 13:50, Martin Dias wrote:
> >>
> >>> Hi all
> >>>
> >>> Last months I and Tristan have been working on Fuel project, an object
> >>> binary serialization tool. The idea is that objects are much more
> >>> times loaded than stored, therefore it is worth to spend time while
> >>> storing in order to have faster loading and user experience. We
> >>> present an implementation of a pickle format that is based on
> >>> clustering similar objects.
> >>>
> >>> There is a summary of the project below, but more complete information
> >>> is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
> >>>
> >>> The implementation still needs a lot of work to be really useful,
> >>> optimizations should be done, but we'll be glad to get feedback of the
> >>> community.
> >>>
> >>>
> >>> = Pickle format =
> >>>
> >>> The pickle format and the serialization algorithm main idea, is
> >>> explained in this slides:
> >>>
> >>> http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
> >>>
> >>>
> >>> = Current features =
> >>>
> >>> - Class shape changing (when a variable has been added, or removed, or
> >>> its index changed)
> >>> - Serialize most of the basic objects.
> >>> - Serialize (almost) any CompiledMethod
> >>> - Detection of global or class variables
> >>> - Support for cyclic object graphs
> >>> - Tests
> >>>
> >>>
> >>> = Next steps =
> >>>
> >>> - Improve version checking.
> >>> - Optimize performance.
> >>> - Serialize more kinds of objects:
> >>> -- Class with its complete description.
> >>> -- Method contexts
> >>> -- Active block closures
> >>> -- Continuation
> >>> - Some improvements for the user:
> >>> -- pre and post actions to be executed.
> >>> -- easily say 'this object is singleton'.
> >>> - Partial loading of a stored graph.
> >>> - Fast statistics/brief info extraction of a stored graph.
> >>> - ConfigurationOfFuel.
> >>> - Be able to deploy materialization behavior only (independent from
> >>> the serialization behavior)
> >>>
> >>>
> >>> = Download =
> >>>
> >>> In a Pharo 1.1 or 1.1.1 evaluate:
> >>>
> >>> Gofer new
> >>> squeaksource: 'Fuel';
> >>> version: 'Fuel-MartinDias.74';
> >>> version: 'FuelBenchmarks-MartinDias.4';
> >>> load.
> >>>
> >>>
> >>> = Benchmarks =
> >>>
> >>> You can run benchmarks executing this line (results in Transcript):
> >>>
> >>> FLBenchmarks newBasic run.
> >>>
> >>>
> >>> Thank you!
> >>> Martin Dias
> >>>
> >>
> >> --
> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >> Alexandre Bergel  http://www.bergel.eu
> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>

[Pharo-project] I will publish SimpleMorphic in PharoTaskForces

[Stéphane Ducasse]

Hi guys

I will publish SimpleMorphic in PharoTaskForces and I suggest that we include 
it in the core so that it does not rot.
Then I will check if I find some times to clean the first items like 
FillinTheBlank and friends.

Stef

Re: [Pharo-project] Smalltalk in small steps ?

[James Ladd]

>>Perhaps most importantly, you may find that, like literate programming, the 
>>effort to explain your decisions and implementation in prose may very well 
>>improve the code.

Im hoping this is the case.

  

Re: [Pharo-project] Fuel - a fast object deployment tool

[Stéphane Ducasse]

alex this is good candidate for your profiler :)

Stef

On Dec 8, 2010, at 9:05 PM, Alexandre Bergel wrote:

>>> It look cool!
>>> Is this a better ImageSegment?
>> 
>> there is no VM code implied and you do not get all the problems of 
>> imageSegment.
>> You should ask is it better than SmartRefStreams.
>> Yes
>> Now the code has not been optimized
> 
> Ah ok! How to deal with stubs is the difference with ImageSegment then.
> 
> It looks exciting!
> 
> Alexandre
> 
> 
>> 
>>> 
>>> Alexandre
>>> 
>>> 
>>> On 8 Dec 2010, at 13:50, Martin Dias wrote:
>>> 
 Hi all
 
 Last months I and Tristan have been working on Fuel project, an object
 binary serialization tool. The idea is that objects are much more
 times loaded than stored, therefore it is worth to spend time while
 storing in order to have faster loading and user experience. We
 present an implementation of a pickle format that is based on
 clustering similar objects.
 
 There is a summary of the project below, but more complete information
 is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
 
 The implementation still needs a lot of work to be really useful,
 optimizations should be done, but we'll be glad to get feedback of the
 community.
 
 
 = Pickle format =
 
 The pickle format and the serialization algorithm main idea, is
 explained in this slides:
 
 http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
 
 
 = Current features =
 
 - Class shape changing (when a variable has been added, or removed, or
 its index changed)
 - Serialize most of the basic objects.
 - Serialize (almost) any CompiledMethod
 - Detection of global or class variables
 - Support for cyclic object graphs
 - Tests
 
 
 = Next steps =
 
 - Improve version checking.
 - Optimize performance.
 - Serialize more kinds of objects:
 -- Class with its complete description.
 -- Method contexts
 -- Active block closures
 -- Continuation
 - Some improvements for the user:
 -- pre and post actions to be executed.
 -- easily say 'this object is singleton'.
 - Partial loading of a stored graph.
 - Fast statistics/brief info extraction of a stored graph.
 - ConfigurationOfFuel.
 - Be able to deploy materialization behavior only (independent from
 the serialization behavior)
 
 
 = Download =
 
 In a Pharo 1.1 or 1.1.1 evaluate:
 
 Gofer new
squeaksource: 'Fuel';
version: 'Fuel-MartinDias.74';
version: 'FuelBenchmarks-MartinDias.4';
load.
 
 
 = Benchmarks =
 
 You can run benchmarks executing this line (results in Transcript):
 
 FLBenchmarks newBasic run.
 
 
 Thank you!
 Martin Dias
 
>>> 
>>> -- 
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 
> 
> 

Re: [Pharo-project] ODBC, loadFFI and friends!

[Luc Fabresse]

Hi Benoit,

 FFI is an external package that you should load.
 Mariano explained how to do it in a previous message here:
http://forum.world.st/Is-FFI-installation-broken-td3061587.html#a3061643

#Luc


2010/12/8 Benoit St-Jean 

> I have downloaded the 1.1.1 Pharo "One Click" image and I am trying to load
> the ODBC package from squeaksource.  FFI stuff is obviously missing...
>
> What happened to the ScriptLoader>>#loadFFI method?
>
> How should I load ODBC ?  Am I missing something?
>
> Thanks!
>
> -
> Benoit St-Jean
> Yahoo! Messenger: bstjean
> A standpoint is an intellectual horizon of radius zero.
> (Albert Einstein)
>
>

[Pharo-project] Issue 3388 in pharo: Fix some red tests in Pharo1.2

[pharo]

Status: Fixed
Owner: stephane.ducasse
Labels: Milestone-1.2

New issue 3388 by stephane.ducasse: Fix some red tests in Pharo1.2
http://code.google.com/p/pharo/issues/detail?id=3388

marcus I started to fix some tests. These two ones are ready for inclusion.

Attachments:
fixingSystemNavigationtests.2.cs  1.3 KB

[Pharo-project] About using pragma for help like in setting

[Stéphane Ducasse]

Hi guys

yesterday on the irc we got a discussion on the dependency introduced when 
using HelpSystem.
Some proposed to used pragmas like in settings since they work well for setting 
and we can also browse help 
with implementors.

Torsten do you have a word to say before we start to implement this solution?

Stef

[Pharo-project] ODBC, loadFFI and friends!

[Benoit St-Jean]

I have downloaded the 1.1.1 Pharo "One Click" image and I am trying to load the 
ODBC package from squeaksource.  FFI stuff is obviously missing...

What happened to the ScriptLoader>>#loadFFI method?

How should I load ODBC ?  Am I missing something?

Thanks!

 -
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

Re: [Pharo-project] Fuel - a fast object deployment tool

[Alexandre Bergel]

>> It look cool!
>> Is this a better ImageSegment?
> 
> there is no VM code implied and you do not get all the problems of 
> imageSegment.
> You should ask is it better than SmartRefStreams.
> Yes
> Now the code has not been optimized

Ah ok! How to deal with stubs is the difference with ImageSegment then.

It looks exciting!

Alexandre


> 
>> 
>> Alexandre
>> 
>> 
>> On 8 Dec 2010, at 13:50, Martin Dias wrote:
>> 
>>> Hi all
>>> 
>>> Last months I and Tristan have been working on Fuel project, an object
>>> binary serialization tool. The idea is that objects are much more
>>> times loaded than stored, therefore it is worth to spend time while
>>> storing in order to have faster loading and user experience. We
>>> present an implementation of a pickle format that is based on
>>> clustering similar objects.
>>> 
>>> There is a summary of the project below, but more complete information
>>> is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
>>> 
>>> The implementation still needs a lot of work to be really useful,
>>> optimizations should be done, but we'll be glad to get feedback of the
>>> community.
>>> 
>>> 
>>> = Pickle format =
>>> 
>>> The pickle format and the serialization algorithm main idea, is
>>> explained in this slides:
>>> 
>>> http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
>>> 
>>> 
>>> = Current features =
>>> 
>>> - Class shape changing (when a variable has been added, or removed, or
>>> its index changed)
>>> - Serialize most of the basic objects.
>>> - Serialize (almost) any CompiledMethod
>>> - Detection of global or class variables
>>> - Support for cyclic object graphs
>>> - Tests
>>> 
>>> 
>>> = Next steps =
>>> 
>>> - Improve version checking.
>>> - Optimize performance.
>>> - Serialize more kinds of objects:
>>> -- Class with its complete description.
>>> -- Method contexts
>>> -- Active block closures
>>> -- Continuation
>>> - Some improvements for the user:
>>> -- pre and post actions to be executed.
>>> -- easily say 'this object is singleton'.
>>> - Partial loading of a stored graph.
>>> - Fast statistics/brief info extraction of a stored graph.
>>> - ConfigurationOfFuel.
>>> - Be able to deploy materialization behavior only (independent from
>>> the serialization behavior)
>>> 
>>> 
>>> = Download =
>>> 
>>> In a Pharo 1.1 or 1.1.1 evaluate:
>>> 
>>> Gofer new
>>> squeaksource: 'Fuel';
>>> version: 'Fuel-MartinDias.74';
>>> version: 'FuelBenchmarks-MartinDias.4';
>>> load.
>>> 
>>> 
>>> = Benchmarks =
>>> 
>>> You can run benchmarks executing this line (results in Transcript):
>>> 
>>> FLBenchmarks newBasic run.
>>> 
>>> 
>>> Thank you!
>>> Martin Dias
>>> 
>> 
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

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

Re: [Pharo-project] Morph wont delete in pharo, cant select it...

[Stéphane Ducasse]

don't cry...

Try alt + shift + click to bring the halos.

We did it like that else the halos gets really in your way all the time.

Stef


On Dec 8, 2010, at 8:55 PM, Joseph T. Bore wrote:

> 
> ive had my fingers in knots over here trying what seems like every 
> control/alt/shift left button/right button combination.  
> 
> control is usually the way to get the alternate click on a mac with one 
> button but this is the third button. im having no luck.
> 
> 
> 
> 
> On Dec 8, 2010, at 2:52 PM, Gary Chambers wrote:
> 
>> Not sure, having no Mac (only iPad etc...)
>> Try opt-shift clicks perhaps?
>> Shift is a definite component of the magic combination!
>> 
>> Regards, Gary
>> 
>> - Original Message - From: "Joseph T. Bore" 
>> To: 
>> Sent: Wednesday, December 08, 2010 7:36 PM
>> Subject: Re: [Pharo-project] Morph wont delete in pharo, cant select it...
>> 
>> 
>> 
>> anyway to get that on a mac with a 2 button mouse?  im on a laptop, i have 2 
>> buttons, but not three.  is there some preference that can be set to give me 
>> access to that?
>> 
>> 
>> On Dec 8, 2010, at 2:28 PM, Gary Chambers wrote:
>> 
>>> Try shift-mid-click on morph for halo.
>>> 
>>> Regards, Gary
>>> 
>>> - Original Message - From: "Joseph T. Bore" 
>>> To: 
>>> Sent: Wednesday, December 08, 2010 7:16 PM
>>> Subject: [Pharo-project] Morph wont delete in pharo, cant select it...
>>> 
>>> 
>>> 
>>> am i doing something obviously wrong?:
>>> 
>>> i have downloaded Pharo 1.1.1 (single click) for Mac OSX
>>> 
>>> bring up the image then:
>>> 
>>> Morph new openInWorld, do it.  (get a nice blue square, perfect)
>>> 
>>> click to pick it up and move it around, all is well
>>> 
>>> control click, brings up menu for morph
>>> 
>>> here is where the problems start
>>> 
>>> delete menu option, Blue square wont go away...
>>> 
>>> add halos menu option gives halos but they are on the PasteupMorph (the 
>>> desktop i think).
>>> 
>>> i cant find any way to get rid of this morph, will i have a blue friend 
>>> forever?
>>> 
>>> im sure im doing something obviously wrong, just dont know what it is...
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-project] Morph wont delete in pharo, cant select it...

[Francisco Ortiz Peñaloza]

Hi,

first try Inspect on the control click menu, pick the morph and an inspector
should show up. On the right side of the inspector write "self delete" and
execute it.

Cheers,
Francisco

On Wed, Dec 8, 2010 at 5:36 PM, Joseph T. Bore  wrote:

>
> anyway to get that on a mac with a 2 button mouse?  im on a laptop, i have
> 2 buttons, but not three.  is there some preference that can be set to give
> me access to that?
>
>
> On Dec 8, 2010, at 2:28 PM, Gary Chambers wrote:
>
> > Try shift-mid-click on morph for halo.
> >
> > Regards, Gary
> >
> > - Original Message - From: "Joseph T. Bore" 
> > To: 
> > Sent: Wednesday, December 08, 2010 7:16 PM
> > Subject: [Pharo-project] Morph wont delete in pharo, cant select it...
> >
> >
> >
> > am i doing something obviously wrong?:
> >
> > i have downloaded Pharo 1.1.1 (single click) for Mac OSX
> >
> > bring up the image then:
> >
> > Morph new openInWorld, do it.  (get a nice blue square, perfect)
> >
> > click to pick it up and move it around, all is well
> >
> > control click, brings up menu for morph
> >
> > here is where the problems start
> >
> > delete menu option, Blue square wont go away...
> >
> > add halos menu option gives halos but they are on the PasteupMorph (the
> desktop i think).
> >
> > i cant find any way to get rid of this morph, will i have a blue friend
> forever?
> >
> > im sure im doing something obviously wrong, just dont know what it is...
> >
> >
> >
>
>
>

Re: [Pharo-project] Morph wont delete in pharo, cant select it...

[Joseph T. Bore]

ive had my fingers in knots over here trying what seems like every 
control/alt/shift left button/right button combination.  

control is usually the way to get the alternate click on a mac with one button 
but this is the third button. im having no luck.




On Dec 8, 2010, at 2:52 PM, Gary Chambers wrote:

> Not sure, having no Mac (only iPad etc...)
> Try opt-shift clicks perhaps?
> Shift is a definite component of the magic combination!
> 
> Regards, Gary
> 
> - Original Message - From: "Joseph T. Bore" 
> To: 
> Sent: Wednesday, December 08, 2010 7:36 PM
> Subject: Re: [Pharo-project] Morph wont delete in pharo, cant select it...
> 
> 
> 
> anyway to get that on a mac with a 2 button mouse?  im on a laptop, i have 2 
> buttons, but not three.  is there some preference that can be set to give me 
> access to that?
> 
> 
> On Dec 8, 2010, at 2:28 PM, Gary Chambers wrote:
> 
>> Try shift-mid-click on morph for halo.
>> 
>> Regards, Gary
>> 
>> - Original Message - From: "Joseph T. Bore" 
>> To: 
>> Sent: Wednesday, December 08, 2010 7:16 PM
>> Subject: [Pharo-project] Morph wont delete in pharo, cant select it...
>> 
>> 
>> 
>> am i doing something obviously wrong?:
>> 
>> i have downloaded Pharo 1.1.1 (single click) for Mac OSX
>> 
>> bring up the image then:
>> 
>> Morph new openInWorld, do it.  (get a nice blue square, perfect)
>> 
>> click to pick it up and move it around, all is well
>> 
>> control click, brings up menu for morph
>> 
>> here is where the problems start
>> 
>> delete menu option, Blue square wont go away...
>> 
>> add halos menu option gives halos but they are on the PasteupMorph (the 
>> desktop i think).
>> 
>> i cant find any way to get rid of this morph, will i have a blue friend 
>> forever?
>> 
>> im sure im doing something obviously wrong, just dont know what it is...
>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-project] Morph wont delete in pharo, cant select it...

[Gary Chambers]

Not sure, having no Mac (only iPad etc...)
Try opt-shift clicks perhaps?
Shift is a definite component of the magic combination!

Regards, Gary

- Original Message - 
From: "Joseph T. Bore" 

To: 
Sent: Wednesday, December 08, 2010 7:36 PM
Subject: Re: [Pharo-project] Morph wont delete in pharo, cant select it...



anyway to get that on a mac with a 2 button mouse?  im on a laptop, i have 2 
buttons, but not three.  is there some preference that can be set to give me 
access to that?



On Dec 8, 2010, at 2:28 PM, Gary Chambers wrote:


Try shift-mid-click on morph for halo.

Regards, Gary

- Original Message - From: "Joseph T. Bore" 
To: 
Sent: Wednesday, December 08, 2010 7:16 PM
Subject: [Pharo-project] Morph wont delete in pharo, cant select it...



am i doing something obviously wrong?:

i have downloaded Pharo 1.1.1 (single click) for Mac OSX

bring up the image then:

Morph new openInWorld, do it.  (get a nice blue square, perfect)

click to pick it up and move it around, all is well

control click, brings up menu for morph

here is where the problems start

delete menu option, Blue square wont go away...

add halos menu option gives halos but they are on the PasteupMorph (the 
desktop i think).


i cant find any way to get rid of this morph, will i have a blue friend 
forever?


im sure im doing something obviously wrong, just dont know what it is...

Re: [Pharo-project] Fuel - a fast object deployment tool

[Stéphane Ducasse]

On Dec 8, 2010, at 8:42 PM, Alexandre Bergel wrote:

> It look cool!
> Is this a better ImageSegment?

there is no VM code implied and you do not get all the problems of imageSegment.
You should ask is it better than SmartRefStreams.
Yes
Now the code has not been optimized

> 
> Alexandre
> 
> 
> On 8 Dec 2010, at 13:50, Martin Dias wrote:
> 
>> Hi all
>> 
>> Last months I and Tristan have been working on Fuel project, an object
>> binary serialization tool. The idea is that objects are much more
>> times loaded than stored, therefore it is worth to spend time while
>> storing in order to have faster loading and user experience. We
>> present an implementation of a pickle format that is based on
>> clustering similar objects.
>> 
>> There is a summary of the project below, but more complete information
>> is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
>> 
>> The implementation still needs a lot of work to be really useful,
>> optimizations should be done, but we'll be glad to get feedback of the
>> community.
>> 
>> 
>> = Pickle format =
>> 
>> The pickle format and the serialization algorithm main idea, is
>> explained in this slides:
>> 
>> http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
>> 
>> 
>> = Current features =
>> 
>> - Class shape changing (when a variable has been added, or removed, or
>> its index changed)
>> - Serialize most of the basic objects.
>> - Serialize (almost) any CompiledMethod
>> - Detection of global or class variables
>> - Support for cyclic object graphs
>> - Tests
>> 
>> 
>> = Next steps =
>> 
>> - Improve version checking.
>> - Optimize performance.
>> - Serialize more kinds of objects:
>> -- Class with its complete description.
>> -- Method contexts
>> -- Active block closures
>> -- Continuation
>> - Some improvements for the user:
>> -- pre and post actions to be executed.
>> -- easily say 'this object is singleton'.
>> - Partial loading of a stored graph.
>> - Fast statistics/brief info extraction of a stored graph.
>> - ConfigurationOfFuel.
>> - Be able to deploy materialization behavior only (independent from
>> the serialization behavior)
>> 
>> 
>> = Download =
>> 
>> In a Pharo 1.1 or 1.1.1 evaluate:
>> 
>> Gofer new
>>  squeaksource: 'Fuel';
>>  version: 'Fuel-MartinDias.74';
>>  version: 'FuelBenchmarks-MartinDias.4';
>>  load.
>> 
>> 
>> = Benchmarks =
>> 
>> You can run benchmarks executing this line (results in Transcript):
>> 
>> FLBenchmarks newBasic run.
>> 
>> 
>> Thank you!
>> Martin Dias
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 
> 
> 

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

[Levente Uzonyi]

On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:


Levente,

that's weird, i'm sending you a screenshot i'm running PharoCore 12271
with Ocompletion-ul.88 loaded


Right, I forgot to change the ToolSet to ECToolSet. Now I see the problem.



I really like how you clear the way with these two questions,
- should OCompletion be used in that panel?
- should that panel use TextEditor instead of SmalltalkEditor?

Using OCompletion is ok i think, in another email i said that having two way
autocompletion with the TextEditor element and the recent WHATEVER used list
above dont make sense to me, but some argue that they use their mouse to go
to a recently used class.

i think the finder window should be minimal, just the input text element -no
recent used list- and have autocompletion (ie. web autocompletion). As web
users we see that a lot, i will not miss the recent WHATEVER list.


A big +1 (note that I'm not a Pharo user). If there's need for the recent
classes, then it should be available via a different menu item + shortcut.



On your second question, imho we're trying to find a Smalltalk class or
Smalltalk WHATEVER, could be better to have a SmalltalkEditor instance
instead of TextEditor one.


If the idea is to keep this tool this way (recent classes list + no 
autocompleter), then I'd probably change it to SmalltalkEditor. But adding 
the method #model to TextMorph will "fix" this problem anyway.



Levente



Cheers,
Francisco

[image: PharoScreenshot.1.png]

On Wed, Dec 8, 2010 at 4:20 AM, Alain Plantec  wrote:


I agree with Levente. The basic completion (cmd-q) is also only usable with
a SmalltalkEditor.
Cheers
Alain

Le 08/12/2010 03:58, Levente Uzonyi a écrit :

 On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:


 So Levente you're saying that given the following use case you musn't add

#model to TextEditor but change TextEditor collaboration with an instance
of
SmalltalkEditor

OCompletion works well to edit code in the system browser as is, the DNU
occurs when as an example you do a class find (Cmd+f) on SystemBrowser
and
you start typing on that "Class name or fragment" window looking for
something.



Adding the accessor is fine of course, it may be useful for other things
too. I'm saying that OCompletion is intended to work in places where code
completion is necessary and those places are usually SmalltalkEditors. There
are two things to think about:
- should OCompletion be used in that panel?
- should that panel use TextEditor instead of SmalltalkEditor?

Btw using the latest version of PharoCore (12271) I can't reproduce the
error in the way you described it.


Levente



Cheers,
Francisco

On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi  wrote:

 On Tue, 7 Dec 2010, ph...@googlecode.com wrote:


 Status: Accepted


Owner: guillermopolito

New issue 3385 by guillermopolito: TextEditor doest not understand
#model
http://code.google.com/p/pharo/issues/detail?id=3385

The accessor should be added to load last version of OCompletion in
Core
1.2



 OCompletion shouldn't be used in a TextEditor. OCompletion is for

Smalltalk
code completion, while TextEditor is intended to be a text editor (ask
Juan). That's why OCompletion adds the model accessor to SmalltalkEditor
and
not to TextEditor.


Levente

Re: [Pharo-project] Fuel - a fast object deployment tool

[Alexandre Bergel]

It look cool!
Is this a better ImageSegment?

Alexandre


On 8 Dec 2010, at 13:50, Martin Dias wrote:

> Hi all
> 
> Last months I and Tristan have been working on Fuel project, an object
> binary serialization tool. The idea is that objects are much more
> times loaded than stored, therefore it is worth to spend time while
> storing in order to have faster loading and user experience. We
> present an implementation of a pickle format that is based on
> clustering similar objects.
> 
> There is a summary of the project below, but more complete information
> is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
> 
> The implementation still needs a lot of work to be really useful,
> optimizations should be done, but we'll be glad to get feedback of the
> community.
> 
> 
> = Pickle format =
> 
> The pickle format and the serialization algorithm main idea, is
> explained in this slides:
> 
> http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
> 
> 
> = Current features =
> 
> - Class shape changing (when a variable has been added, or removed, or
> its index changed)
> - Serialize most of the basic objects.
> - Serialize (almost) any CompiledMethod
> - Detection of global or class variables
> - Support for cyclic object graphs
> - Tests
> 
> 
> = Next steps =
> 
> - Improve version checking.
> - Optimize performance.
> - Serialize more kinds of objects:
> -- Class with its complete description.
> -- Method contexts
> -- Active block closures
> -- Continuation
> - Some improvements for the user:
> -- pre and post actions to be executed.
> -- easily say 'this object is singleton'.
> - Partial loading of a stored graph.
> - Fast statistics/brief info extraction of a stored graph.
> - ConfigurationOfFuel.
> - Be able to deploy materialization behavior only (independent from
> the serialization behavior)
> 
> 
> = Download =
> 
> In a Pharo 1.1 or 1.1.1 evaluate:
> 
> Gofer new
>   squeaksource: 'Fuel';
>   version: 'Fuel-MartinDias.74';
>   version: 'FuelBenchmarks-MartinDias.4';
>   load.
> 
> 
> = Benchmarks =
> 
> You can run benchmarks executing this line (results in Transcript):
> 
> FLBenchmarks newBasic run.
> 
> 
> Thank you!
> Martin Dias
> 

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

[Pharo-project] Finder issue?

[Francisco Ortiz Peñaloza]

Hi,

after loading last Shout on PharoCore the new Finder isn't working properly.
Let's see

PluggableShoutMorph>>initialize registers Shout in AppRegistry as the
default MorphicTextEditor but FinderUI>>buildSourceTextArea uses a
PluggableTextMorph.

I think it should be using the more dinamic *MorphicTextEditor
default*insted of the hardcoded PluggableTextMorph. Am i right?

Francisco

Re: [Pharo-project] Morph wont delete in pharo, cant select it...

[Joseph T. Bore]

anyway to get that on a mac with a 2 button mouse?  im on a laptop, i have 2 
buttons, but not three.  is there some preference that can be set to give me 
access to that?


On Dec 8, 2010, at 2:28 PM, Gary Chambers wrote:

> Try shift-mid-click on morph for halo.
> 
> Regards, Gary
> 
> - Original Message - From: "Joseph T. Bore" 
> To: 
> Sent: Wednesday, December 08, 2010 7:16 PM
> Subject: [Pharo-project] Morph wont delete in pharo, cant select it...
> 
> 
> 
> am i doing something obviously wrong?:
> 
> i have downloaded Pharo 1.1.1 (single click) for Mac OSX
> 
> bring up the image then:
> 
> Morph new openInWorld, do it.  (get a nice blue square, perfect)
> 
> click to pick it up and move it around, all is well
> 
> control click, brings up menu for morph
> 
> here is where the problems start
> 
> delete menu option, Blue square wont go away...
> 
> add halos menu option gives halos but they are on the PasteupMorph (the 
> desktop i think).
> 
> i cant find any way to get rid of this morph, will i have a blue friend 
> forever?
> 
> im sure im doing something obviously wrong, just dont know what it is...
> 
> 
> 

Re: [Pharo-project] Morph wont delete in pharo, cant select it...

[Gary Chambers]

Try shift-mid-click on morph for halo.

Regards, Gary

- Original Message - 
From: "Joseph T. Bore" 

To: 
Sent: Wednesday, December 08, 2010 7:16 PM
Subject: [Pharo-project] Morph wont delete in pharo, cant select it...



am i doing something obviously wrong?:

i have downloaded Pharo 1.1.1 (single click) for Mac OSX

bring up the image then:

Morph new openInWorld, do it.  (get a nice blue square, perfect)

click to pick it up and move it around, all is well

control click, brings up menu for morph

here is where the problems start

delete menu option, Blue square wont go away...

add halos menu option gives halos but they are on the PasteupMorph (the 
desktop i think).


i cant find any way to get rid of this morph, will i have a blue friend 
forever?


im sure im doing something obviously wrong, just dont know what it is...

[Pharo-project] Morph wont delete in pharo, cant select it...

[Joseph T. Bore]

am i doing something obviously wrong?:

i have downloaded Pharo 1.1.1 (single click) for Mac OSX

bring up the image then:  

Morph new openInWorld, do it.  (get a nice blue square, perfect)

click to pick it up and move it around, all is well

control click, brings up menu for morph

here is where the problems start

delete menu option, Blue square wont go away...

add halos menu option gives halos but they are on the PasteupMorph (the 
desktop i think).

i cant find any way to get rid of this morph, will i have a blue friend forever?

im sure im doing something obviously wrong, just dont know what it is...

Re: [Pharo-project] Popularity or not of smalltalk?

[Alexandre Bergel]

What is a reentrant interpret?

Alexandre


On 8 Dec 2010, at 14:00, Stéphane Ducasse wrote:

>> 
>> 
>> Indeed.  An immature FFI, lack of dll options etc.  Integration is indeed 
>> one of the biggest weaknesses.  But we're making progress here.  So things 
>> may be different in months, if not years.
> 
> Eliot did you get interpret reentrant?
> Because we are discussing that point with igor and yes we want that to have :)
> 
> Stef
> 
> 

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

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Stéphane Ducasse]

I know. Still showing the way is often important.

On Dec 8, 2010, at 7:24 PM, Yanni Chiu wrote:

> Lukas and Philippe brought it to its current state. I just did the first 
> version.
> 
> On 08/12/10 12:21 PM, Stéphane Ducasse wrote:
>> Yes Thanks Yanni for your code.
>> We have a lot of ideas on what to do with automated build servers :)
>> This is just the start. I was dreaming on that while listening pelrine talk 
>> at ESUG 2002 on Cruse control...
>> May be we should have built something by then 
>> 
>> Stef
> 
> 

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Yanni Chiu]

Lukas and Philippe brought it to its current state. I just did the first 
version.


On 08/12/10 12:21 PM, Stéphane Ducasse wrote:

Yes Thanks Yanni for your code.
We have a lot of ideas on what to do with automated build servers :)
This is just the start. I was dreaming on that while listening pelrine talk at 
ESUG 2002 on Cruse control...
May be we should have built something by then 

Stef

Re: [Pharo-project] Popularity or not of smalltalk?

[Eliot Miranda]

On Wed, Dec 8, 2010 at 9:00 AM, Stéphane Ducasse
wrote:

> >
> >
> > Indeed.  An immature FFI, lack of dll options etc.  Integration is indeed
> one of the biggest weaknesses.  But we're making progress here.  So things
> may be different in months, if not years.
>
> Eliot did you get interpret reentrant?
>

I have a prototype reentrant FFI that can do threaded call-outs and receive
threaded callbacks. I was demoing it in Argentina but my demo locks up the
UI (not the entire image thoguh) so it is not by any means production-ready.
 I need to find time to finish it.  That's not going to happen in the next
two months.  I'll see what can be done to get it released in an unfinished
state so that others can work on it.

best
Eliot



> Because we are discussing that point with igor and yes we want that to have
> :)
>
> Stef
>
>
>

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Stéphane Ducasse]

Yes Thanks Yanni for your code.
We have a lot of ideas on what to do with automated build servers :)
This is just the start. I was dreaming on that while listening pelrine talk at 
ESUG 2002 on Cruse control...
May be we should have built something by then 

Stef



 Gofer it squeaksource: 'MetacelloRepository';
 package: 'ConfigurationOfPharo';
 load.
 
 (ConfigurationOfPharo project version: '1.2-beta2') load.
 
 Can Hudson help us in building Dev images?
>>> 
>>> Yes, will set up a build for 1.2 today.
>> 
>> I have set one up that takes 1.2 core, runs updates and then tries to
>> build dev
>> 
>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/
>> 
>> It is failing right now.
>> 
>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console
> 
> This build would flag changes to PharoCore-1.2 that break Pharo(Dev) 
> 1.2-beta2. But those core changes may be legitimate, and the fix needs to be 
> done in Pharo(Dev).
> 
> Maybe there should be a second build for Pharo(Dev) 1.2-baseline. The trigger 
> ought to be any change to a package included in the baseline, but that seems 
> difficult to determine. So, maybe once a day, as well as triggering on a 
> change to ConfigurationOfPharo itself.
> 
> BTW, It's great that we have automated builds.
> 
> 

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Dale Henrichs]

On 12/08/2010 09:09 AM, Yanni Chiu wrote:

On 08/12/10 6:48 AM, Marcus Denker wrote:


On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote:



On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote:


Gofer it squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfPharo';
load.

(ConfigurationOfPharo project version: '1.2-beta2') load.

Can Hudson help us in building Dev images?


Yes, will set up a build for 1.2 today.


I have set one up that takes 1.2 core, runs updates and then tries to
build dev

https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/

It is failing right now.

https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console


This build would flag changes to PharoCore-1.2 that break Pharo(Dev)
1.2-beta2. But those core changes may be legitimate, and the fix needs
to be done in Pharo(Dev).

Maybe there should be a second build for Pharo(Dev) 1.2-baseline. The
trigger ought to be any change to a package included in the baseline,
but that seems difficult to determine. So, maybe once a day, as well as
triggering on a change to ConfigurationOfPharo itself.

BTW, It's great that we have automated builds.



With the next release of Metacello there will be support for 
programmatically updating a config, so if the baseline build runs clean 
for pharo dev, the development version could be updated automagically 
... folks would always be able to load the dev version and know that at 
least the tests ran clean and that you are within a safe distance of the 
absolute bleeding edge...


Dale

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Yanni Chiu]

On 08/12/10 6:48 AM, Marcus Denker wrote:


On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote:



On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote:


Gofer it squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfPharo';
load.

(ConfigurationOfPharo project version: '1.2-beta2') load.

Can Hudson help us in building Dev images?


Yes, will set up a build for 1.2 today.


I have set one up that takes 1.2 core, runs updates and then tries to
build dev

https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/

It is failing right now.

https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console


This build would flag changes to PharoCore-1.2 that break Pharo(Dev) 
1.2-beta2. But those core changes may be legitimate, and the fix needs 
to be done in Pharo(Dev).


Maybe there should be a second build for Pharo(Dev) 1.2-baseline. The 
trigger ought to be any change to a package included in the baseline, 
but that seems difficult to determine. So, maybe once a day, as well as 
triggering on a change to ConfigurationOfPharo itself.


BTW, It's great that we have automated builds.

Re: [Pharo-project] Fuel - a fast object deployment tool

[Stéphane Ducasse]

Thanks martin.

Stef

On Dec 8, 2010, at 5:50 PM, Martin Dias wrote:

> Hi all
> 
> Last months I and Tristan have been working on Fuel project, an object
> binary serialization tool. The idea is that objects are much more
> times loaded than stored, therefore it is worth to spend time while
> storing in order to have faster loading and user experience. We
> present an implementation of a pickle format that is based on
> clustering similar objects.
> 
> There is a summary of the project below, but more complete information
> is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel
> 
> The implementation still needs a lot of work to be really useful,
> optimizations should be done, but we'll be glad to get feedback of the
> community.
> 
> 
> = Pickle format =
> 
> The pickle format and the serialization algorithm main idea, is
> explained in this slides:
> 
> http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example
> 
> 
> = Current features =
> 
> - Class shape changing (when a variable has been added, or removed, or
> its index changed)
> - Serialize most of the basic objects.
> - Serialize (almost) any CompiledMethod
> - Detection of global or class variables
> - Support for cyclic object graphs
> - Tests
> 
> 
> = Next steps =
> 
> - Improve version checking.
> - Optimize performance.
> - Serialize more kinds of objects:
> -- Class with its complete description.
> -- Method contexts
> -- Active block closures
> -- Continuation
> - Some improvements for the user:
> -- pre and post actions to be executed.
> -- easily say 'this object is singleton'.
> - Partial loading of a stored graph.
> - Fast statistics/brief info extraction of a stored graph.
> - ConfigurationOfFuel.
> - Be able to deploy materialization behavior only (independent from
> the serialization behavior)
> 
> 
> = Download =
> 
> In a Pharo 1.1 or 1.1.1 evaluate:
> 
> Gofer new
>   squeaksource: 'Fuel';
>   version: 'Fuel-MartinDias.74';
>   version: 'FuelBenchmarks-MartinDias.4';
>   load.
> 
> 
> = Benchmarks =
> 
> You can run benchmarks executing this line (results in Transcript):
> 
> FLBenchmarks newBasic run.
> 
> 
> Thank you!
> Martin Dias
> 

Re: [Pharo-project] Popularity or not of smalltalk?

[Stéphane Ducasse]

> 
> 
> Indeed.  An immature FFI, lack of dll options etc.  Integration is indeed one 
> of the biggest weaknesses.  But we're making progress here.  So things may be 
> different in months, if not years.

Eliot did you get interpret reentrant?
Because we are discussing that point with igor and yes we want that to have :)

Stef

[Pharo-project] Fuel - a fast object deployment tool

[Martin Dias]

Hi all

Last months I and Tristan have been working on Fuel project, an object
binary serialization tool. The idea is that objects are much more
times loaded than stored, therefore it is worth to spend time while
storing in order to have faster loading and user experience. We
present an implementation of a pickle format that is based on
clustering similar objects.

There is a summary of the project below, but more complete information
is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel

The implementation still needs a lot of work to be really useful,
optimizations should be done, but we'll be glad to get feedback of the
community.


= Pickle format =

The pickle format and the serialization algorithm main idea, is
explained in this slides:

http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example


= Current features =

- Class shape changing (when a variable has been added, or removed, or
its index changed)
- Serialize most of the basic objects.
- Serialize (almost) any CompiledMethod
- Detection of global or class variables
- Support for cyclic object graphs
- Tests


= Next steps =

- Improve version checking.
- Optimize performance.
- Serialize more kinds of objects:
-- Class with its complete description.
-- Method contexts
-- Active block closures
-- Continuation
- Some improvements for the user:
-- pre and post actions to be executed.
-- easily say 'this object is singleton'.
- Partial loading of a stored graph.
- Fast statistics/brief info extraction of a stored graph.
- ConfigurationOfFuel.
- Be able to deploy materialization behavior only (independent from
the serialization behavior)


= Download =

In a Pharo 1.1 or 1.1.1 evaluate:

Gofer new
squeaksource: 'Fuel';
version: 'Fuel-MartinDias.74';
version: 'FuelBenchmarks-MartinDias.4';
load.


= Benchmarks =

You can run benchmarks executing this line (results in Transcript):

FLBenchmarks newBasic run.


Thank you!
Martin Dias

Re: [Pharo-project] Popularity or not of smalltalk?

[Stéphane Ducasse]

jimmie I agree :)

Re: [Pharo-project] Popularity or not of smalltalk?

[Gary Chambers]

Fortunately not the case here at Pinesoft ;-)

Regards, Gary

- Original Message - 
From: "Igor Stasenko" 

To: 
Sent: Wednesday, December 08, 2010 3:50 PM
Subject: Re: [Pharo-project] Popularity or not of smalltalk?



On 8 December 2010 03:16, David T. Lewis  wrote:

Bravo, well and truly stated.

(I can't help but wonder how many folks who talk about this stuff have
actually encountered an "Enterprise" in real life, and if so why they
are still so eager to impress these people, much less go to work for 
them.)




Yeah.. It is familiar attitude towards big companies, which i don't 
sharing.


It is starting from first small things, like "i am so proud that i
working in huge company" ,
which immediately rings the bell in my head with a thought: "so, maybe
you should start paying this company for being an employee of it?"

All this shit: thinking BIG , we are big, we are many.. the common
enterprise-level indoctrination , which have nothing to do with
a) productivity
b) efficiency
c) quality of products/services
and could even have a reverse effect.

So, that's why i DON'T care what enterprise-level people doing and
what they thinking about smalltalk. I KNOW that whatever they do, they
doing it wrong :)



Thanks Jimmy, you have captured a lot of positive energy in a few words.

Dave


Jimmie







--
Best regards,
Igor Stasenko AKA sig.

Re: [Pharo-project] Popularity or not of smalltalk?

[Igor Stasenko]

On 8 December 2010 03:16, David T. Lewis  wrote:
> Bravo, well and truly stated.
>
> (I can't help but wonder how many folks who talk about this stuff have
> actually encountered an "Enterprise" in real life, and if so why they
> are still so eager to impress these people, much less go to work for them.)
>

Yeah.. It is familiar attitude towards big companies, which i don't sharing.

It is starting from first small things, like "i am so proud that i
working in huge company" ,
which immediately rings the bell in my head with a thought: "so, maybe
you should start paying this company for being an employee of it?"

All this shit: thinking BIG , we are big, we are many.. the common
enterprise-level indoctrination , which have nothing to do with
a) productivity
b) efficiency
c) quality of products/services
and could even have a reverse effect.

So, that's why i DON'T care what enterprise-level people doing and
what they thinking about smalltalk. I KNOW that whatever they do, they
doing it wrong :)


> Thanks Jimmy, you have captured a lot of positive energy in a few words.
>
> Dave
>
>> Jimmie
>
>



-- 
Best regards,
Igor Stasenko AKA sig.

Re: [Pharo-project] Popularity or not of smalltalk?

[Stéphane Ducasse]

James 

can you create separated thread?

Stef

On Dec 6, 2010, at 6:51 AM, James Ladd wrote:

> While pleading for Smalltalk support with a developer from a popular and 
> great IDE company, I got the 
> following response (below)
> 
> Is there anything I can do/show to prove or disprove the popularity of 
> Smalltalk?
> 
> Rgs, James.
> 
> >>Hello James.
> >>About Smalltalk plugin. Weel, I’m not sure Smalltalk has a big audience 
> >>now. I’ve never heard about commercial products based on Smalltalk. 
> >>Here, some statistics http://langpop.com/

Re: [Pharo-project] Beta

[Stéphane Ducasse]

marcus will deal with that.

On Dec 8, 2010, at 3:53 PM, Stanislav Paskalev wrote:

> Does the hudson build for Pharo 1.2 works now ? Please schedule it if
> so and you'll have at least 1 tester :)
> 
> Stanislav Paskalev (solar_sea)
> 
> 
> 
> On Wed, Dec 8, 2010 at 4:39 PM, Stéphane Ducasse
>  wrote:
>> Hi guys
>> 
>> I fixed the bad package name and we are now beta.
>> :)
>> 
>> So we should kill the tests and the pending issues.
>> 
>> Stef
>> 
>> 
> 

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

[Stéphane Ducasse]

On Dec 8, 2010, at 10:48 AM, Lukas Renggli wrote:

> Very cool framework, I like it a lot! I definitely vote to eventually
> replace HTTPSocket with Zinc HTTP Components.

I would love that.
We plan to open 1.3 Unstable 1 of january :)
So if you have code for that let me know :)



> 
> I wonder why ZnFixedClient is not a subclass of ZnHttpClient? I think
> it would be cool to be able to use them polymorphic.
> 
> Lukas
> 
> 
> On 8 December 2010 09:26, Sven Van Caekenberghe  wrote:
>> Norbert,
>> 
>> Thanks for you interest.
>> 
>> On 07 Dec 2010, at 21:14, Norbert Hartl wrote:
>> 
>>> I scanned the code a few days ago. I tried an initial port to gemstone. 
>>> There are quite a few things to do. After discovering that there are really 
>>> big changes from version to version and the existence of classes with 
>>> suffixes Old and New made me stop the effort. I'm really missing a usable 
>>> http client in gemstone but it seemed to be very hard to keep up with the 
>>> port.
>> 
>> This should be much better now: the whole confusion is now gone (the 'Old' 
>> categories and classes were moved into a separate MC package that should not 
>> be loaded unless you want to do historical research; the 'New' has been 
>> removed from existing categories). Please have another look.
>> 
>> I assume that you have read the overview and getting started pages 
>> (http://homepage.mac.com/svc/Zinc-HTTP-Components).
>> 
>> The category 'Zinc-HTTP-Core' contains a object model of the key building 
>> blocks of the HTTP protocol. Except for learning and teaching, this is not 
>> useful on itself. Building on top of the core are the classes in 
>> 'Zinc-HTTP-Server' for various clients and servers. The category 
>> 'Zinc-HTTP-Support' contains helpers for the implementation, many of which 
>> can be considered portability enablers (much like Seaside has them).
>> 
>> Now, why is there not just one good client, why are there 4 different ones ?
>> 
>> Because different users have different requirements, because each of them 
>> has different features, complexity and above all, a different interface. 
>> Part of this is also a search for the ideal API.
>> 
>> ZnClient is the simplest one: some class methods to fire off one shot 
>> requests.
>> 
>> ZnFixedClient is useful to connect to a single server and reuse the 
>> connection for multiple requests, like with a web services API.
>> 
>> ZnHttpClient is a builder like interface (think of Gofer), it also has some 
>> extra features.
>> 
>> ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket 
>> API. In my development images, this is active, which means that all HTTP 
>> functionality (for MC for example) is handled by Zinc HTTP - a case of 
>> eating my own dog food.
>> 
>> On the server side there is ZnServer which can be customized with a delegate 
>> and authorizer. A static web file server, a Monticello server as well as a 
>> Seaside adaptor are available.
>> 
>>> Do you port an existing library to smalltalk or do you figure out how it 
>>> should be done right now? And what do you think about going towards 
>>> cross-platform? This would need a decision if you are willing to integrate 
>>> grease/sport in your client. I can imagine that this is not wanted per se 
>>> because it introduces dependencies. It will be just very hard to do it 
>>> cross-platform if you do not.
>> 
>> The first goal of Zinc HTTP is to be useful for Pharo, to replace existing 
>> HTTP functionality in the image. Hence portability is not high on the list. 
>> Like you said, building on top of a portability layer would mean external 
>> dependencies that would most probably conflict with the first goal. But I am 
>> not against portability (most of the code except for some obvious missing 
>> crypto stuff still runs on Squeak as well). We can always try to find a 
>> solution.
>> 
>> Regards,
>> 
>> Sven
>> 
>> 
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 

[Pharo-project] Issue 3387 in pharo: Package name should not contain crptic characters

[pharo]

Status: Accepted
Owner: stephane.ducasse
Labels: Milestone-1.3 Difficulty-Easy

New issue 3387 by stephane.ducasse: Package name should not contain crptic  
characters

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

We should make sure that we cannot write package with cryptic characters.

Re: [Pharo-project] Beta

[Stanislav Paskalev]

Does the hudson build for Pharo 1.2 works now ? Please schedule it if
so and you'll have at least 1 tester :)

Stanislav Paskalev (solar_sea)



On Wed, Dec 8, 2010 at 4:39 PM, Stéphane Ducasse
 wrote:
> Hi guys
>
> I fixed the bad package name and we are now beta.
> :)
>
> So we should kill the tests and the pending issues.
>
> Stef
>
>

[Pharo-project] Issue 3386 in pharo: DosFileDirectory>> checkName: aFileName fixErrors: fixing

[pharo]

Status: Accepted
Owner: stephane.ducasse
Labels: Milestone-1.2

New issue 3386 by stephane.ducasse: DosFileDirectory>> checkName: aFileName  
fixErrors: fixing

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

DosFileDirectory>>
checkName: aFileName fixErrors: fixing
"Check if the file name contains any invalid characters"
| fName badChars hasBadChars |
fName := super checkName: aFileName fixErrors: fixing.
badChars := (#( $: $< $> $| $/ $\ $? $* $"), ((0 to: 31) collect: [:n | n  
asCharacter])) asSet.

hasBadChars := fName includesAnyOf: badChars.
(hasBadChars and:[fixing not]) ifTrue:[^self error:'Invalid file name'].
hasBadChars ifFalse:[^ fName].
^ fName collect:
[:char | (badChars includes: char)
  ifTrue:[$#]
  ifFalse:[char]]

Re: [Pharo-project] Comments or no integration: a simple choice foryou

[Stéphane Ducasse]

Yes good script.

Stef

On Dec 7, 2010, at 4:35 PM, Alexandre Bergel wrote:

> Indeed. We could also refine it further by identifying the most used classes 
> for a representative sample of the Pharo ecosystem.
> It still says StandardFonts, SystemChangeNotifier, FreeTypeSettings, 
> MCPackage, ... have to be commented
> 
> Alexandre
> 
> 
> On 7 Dec 2010, at 12:29, Gary Chambers wrote:
> 
>> Naturally, every method of a class references its own class as a literal...
>> Also, class-side methods not accounted for.
>> 
>> Easy enough to change the script to higlight only external references:
>> 
>> d := Dictionary new.
>> Smalltalk allClasses, (Smalltalk allClasses collect: [:cls | cls class]) do: 
>> [ :cls |
>> cls methods do: [:cm | (cm literals select: [:l | l isKindOf: Association ])
>> do: [:assoc |
>> (assoc value isBehavior and: [assoc value ~~ cls])
>>  ifTrue: [d at: assoc value put: (d at: assoc value ifAbsentPut: [0] ) + 
>> 1.
>> associations := d associations asSortedCollection: [:a1 :a2 | a2 value < a1 
>> value].
>> associations select: [:ass | ass key comment isNil or: [ass key comment 
>> isEmpty or: [ass key comment asString includesSubString: 'xx']]]
>> 
>> Regards, Gary
>> 
>> - Original Message - From: "Alexandre Bergel" 
>> To: 
>> Sent: Tuesday, December 07, 2010 2:53 PM
>> Subject: Re: [Pharo-project] Comments or no integration: a simple choice 
>> foryou
>> 
>> 
>> A small script that gives the most referenced classes that are not commented:
>> I run the test in an image with Moose and Spy.
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> "Get the number of references per class"
>> d := Dictionary new.
>> Smalltalk allClasses do: [ :cls | cls methods do: [:cm | (cm literals 
>> select: [:l | l isKindOf: Association ])
>> do: [:assoc |
>> (assoc value isBehavior)
>> ifTrue: [d at: assoc value put: (d at: assoc value ifAbsentPut: [0] ) + 
>> 1.
>> associations := d associations asSortedCollection: [:a1 :a2 | a2 value < a1 
>> value].
>> 
>> "Get the classes that are not commented"
>> associations select: [:ass | ass key comment isNil or: [ass key comment 
>> isEmpty or: [ass key comment asString includesSubString: 'xx']]]
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> 
>> The first 30 entries:
>> SortedCollectionTest->307
>> HeapTest->304
>> IntervalTest->250
>> DictionaryTest->192
>> BagTest->167
>> RxMatcherTest->166
>> PluggableTextMorph->149
>> MooseModel->144
>> UIThemeWatery2->132
>> SystemChangeNotifier->132
>> PPSmalltalkParserTests->129
>> FAMIXClassNavigationTest->128
>> PPJavaSyntax->128
>> PPSmalltalkGrammarTests->128
>> RBRefactoryTestDataApp->123
>> NSFileStream->118
>> NSRWBinaryOrTextStream->109
>> LogicalFont->109
>> NSMultiByteBinaryOrTextStream->108
>> UIThemeW2K->103
>> MCWorkingCopy->101
>> BrowserEnvironment->97
>> DemoSettingStyle->94
>> PPJavaLexiconTests->94
>> MCClassDefinition->93
>> NSAbstractInflateStream->92
>> MCWorkingCopyBrowser->91
>> NSCollectionStreamTest->91
>> GMMetaObject->91
>> ExceptionTester->90
>> 
>> 
>> Cheers,
>> Alexandre
>> 
>> 
>> On 7 Dec 2010, at 10:48, Stéphane Ducasse wrote:
>> 
 The good idae is to push and promote people to put class comments, but not 
 to remove not commented classes from Dev, bacause otherise, you will need 
 to remove 80% of the classes.
>>> 
>>> 
>>> So this is simple to start fixing some of them.
>>> I think that without such objectives we will never make any progress and we 
>>> should.
>>> 
>>> so what are the first 5% of packages that are not documented.
>>> 
>>> Stef
>>> 
 The next step would be a Pareto classification, as it can be accepted (I 
 hope) that SUnit has more history (and it is documented elsewhere, like 
 PBE book) than other classes which even the name of it or its methods may 
 be insufficient to arrive at for what is the class.
 
 We should create IRC meetings, sprints, etc. specially targeted to 
 document these classes.
 
 my .01...
 
 --
 Cesar Rabak
 
 
 Em 05/12/2010 20:07, Mariano Martinez Peck < marianop...@gmail.com > 
 escreveu:
 
 On Sun, Dec 5, 2010 at 9:52 PM, Stéphane Ducasse 
  wrote:
 
 Hi guys
 
 I decided that I will not integrate any code that is not documented in 
 Pharo.
 
 I strongly suggest to remove from Pharo-dev packages whose classes are not 
 commented.
 
 
 I think this is not a good idea...look this approx:
 
 
 
 | pharoCorePackages packagesDev nonCommentedClasses totalClasses |
 pharoCorePackages := #('MultilingualTests' 'Morphic' 'ToolBuilder-Kernel' 
 'PackageInfo' 'Polymorph-ToolBuilder' 'Network-Kernel' 'Network-Protocols' 
 'Compiler' 'System-Finalization' 'Settings-Graphics' 'Collections' 
 'Network-RemoteDirectory' 'Traits' 'Network-URI' 'Settings-Display' 
 'Collections-Abstract' 'Settings-Compiler' 'MonticelloMocks' 
 'ScriptLoader11' 'System-Digital Signatures' 'System-Loca

Re: [Pharo-project] Comments or no integration: a simple choice for you

[Stéphane Ducasse]

On Dec 6, 2010, at 7:41 PM, Sean P. DeNigris wrote:

> 
> 
> laurent laffont wrote:
>> 
>>> IMHO, before we take such a stance, we should have a package comment pane
>>> and encourage its use.  A complex package is probably best documented
>>> with a
>>> good high-level description and some type of example(s), which can take
>>> the
>>> form of do-its in a package comment.
>> 
>> HelpSystem does this and is included in PharoCore. See
>> http://www.pharocasts.com/2010/09/document-with-helpsystem.html
>> 
> 
> What if the source pane in the browser showed the first page of the
> package's help when only a package name was selected?  

good first step!

> And there could be a
> shortcut/cataegory-list-menu-option to open the help browser on the
> package's help from the browser!
> 
> Sean
> -- 
> View this message in context: 
> http://forum.world.st/Comments-or-no-integration-a-simple-choice-for-you-tp3073643p3075057.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

[Pharo-project] Beta

[Stéphane Ducasse]

Hi guys

I fixed the bad package name and we are now beta.
:)

So we should kill the tests and the pending issues.

Stef

Re: [Pharo-project] Popularity or not of smalltalk?

[Casimiro de Almeida Barreto]

Em 06-12-2010 13:38, csra...@bol.com.br escreveu:
> James,
>
> The point of your post will surely be answered by other, and I'm sure you'll 
> find good stuff in STIC and ESUG websites.
>
> However, the purpose of yours surprises me: why do you think that having "a 
> popular and great IDE company" "supporting" Smalltalk is of any help?
In the past there were "big companies" "supporting" smalltalk and the
result was no good. If one reads some of smalltalk history he'll see a
spectacle of greed & other bad doings and nasty mistakes by corporations.

The biggest problem with smalltalk itself was that it was far ahead its
time. Now it's not. Further than that, when one sees things like CogVM
coming to life (which enhances performance of applications) and things
being developed in seaside and related tools (pier, magritte, etc) it
becomes clear the advantages of adopting smalltalk, despite some issues
are still recurrent like: the lack of a "foundation classes" definition
(thus much of trunk/pharo/etc changing overtime and requiring constant
attention and maintenance by developers) and lack of documentation
(which is consequence of first issue).
> Decoupling the Smalltalk environment from the "IDE" will make a Frankenstein 
> which will make the acronym 'IDE' look like an oxymoron...
There are some implementations decoupled from IDEs. But in the end of
the day everybody needs a browser, an inspector, a debugger, a
workspace, a Transcript, etc... And nobody really needs to develop a
"windows native", "X Windows native", "aqua/OS-X/iOS native" version of
the same application (at least not that frequently). Anyways, if the
intention is running an application with the "native interface"
deactivated it's always possible to execute smalltalk headless.


Regards

CdAB
> Regards,
>
> --
> Cesar Rabak
>
> Em 06/12/2010 03:51, James Ladd < james_l...@hotmail.com > escreveu:
>
>
> While pleading for Smalltalk support with a developer from a popular and 
> great IDE company, I got the
>
> following response (below)
>
>  
>
> Is there anything I can do/show to prove or disprove the popularity of 
> Smalltalk?
>
>  
>
> Rgs, James.
>
>
>
>
>
>>> Hello James.
>>> About Smalltalk plugin. Weel, I’m not sure Smalltalk has a big audience 
>>> now. I’ve never heard about commercial products based on Smalltalk. 
>>> Here, some statistics http://langpop.com/  
>

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

[Stéphane Ducasse]

On Dec 8, 2010, at 9:26 AM, Sven Van Caekenberghe wrote:

> Norbert,
> 
> Thanks for you interest.
> 
> On 07 Dec 2010, at 21:14, Norbert Hartl wrote:
> 
>> I scanned the code a few days ago. I tried an initial port to gemstone. 
>> There are quite a few things to do. After discovering that there are really 
>> big changes from version to version and the existence of classes with 
>> suffixes Old and New made me stop the effort. I'm really missing a usable 
>> http client in gemstone but it seemed to be very hard to keep up with the 
>> port.
> 
> This should be much better now: the whole confusion is now gone (the 'Old' 
> categories and classes were moved into a separate MC package that should not 
> be loaded unless you want to do historical research; the 'New' has been 
> removed from existing categories). Please have another look.
> 
> I assume that you have read the overview and getting started pages 
> (http://homepage.mac.com/svc/Zinc-HTTP-Components). 
> 
> The category 'Zinc-HTTP-Core' contains a object model of the key building 
> blocks of the HTTP protocol. Except for learning and teaching, this is not 
> useful on itself. Building on top of the core are the classes in 
> 'Zinc-HTTP-Server' for various clients and servers. The category 
> 'Zinc-HTTP-Support' contains helpers for the implementation, many of which 
> can be considered portability enablers (much like Seaside has them).
> 
> Now, why is there not just one good client, why are there 4 different ones ?
> 
> Because different users have different requirements, because each of them has 
> different features, complexity and above all, a different interface. Part of 
> this is also a search for the ideal API.
> 
> ZnClient is the simplest one: some class methods to fire off one shot 
> requests.
> 
> ZnFixedClient is useful to connect to a single server and reuse the 
> connection for multiple requests, like with a web services API.
> 
> ZnHttpClient is a builder like interface (think of Gofer), it also has some 
> extra features.
> 
> ZnHTTPSocketFacade is a replacement for the current

> Pharo/Squeak HTTPSocket API. In my development images, this is active, which 
> means that all HTTP functionality (for MC for example) is handled by Zinc 
> HTTP - a case of eating my own dog food.

good!

> On the server side there is ZnServer which can be customized with a delegate 
> and authorizer. A static web file server, a Monticello server as well as a 
> Seaside adaptor are available.
> 
>> Do you port an existing library to smalltalk or do you figure out how it 
>> should be done right now? And what do you think about going towards 
>> cross-platform? This would need a decision if you are willing to integrate 
>> grease/sport in your client. I can imagine that this is not wanted per se 
>> because it introduces dependencies. It will be just very hard to do it 
>> cross-platform if you do not.
> 
> The first goal of Zinc HTTP is to be useful for Pharo, to replace existing 
> HTTP functionality in the image. Hence portability is not high on the list. 
> Like you said, building on top of a portability layer would mean external 
> dependencies that would most probably conflict with the first goal. But I am 
> not against portability (most of the code except for some obvious missing 
> crypto stuff still runs on Squeak as well). We can always try to find a 
> solution. 
> 
> Regards,
> 
> Sven
> 
> 

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

[Stéphane Ducasse]

>> 
> Thanks for the explanation, some quick and dirty buffering makes a huge 
> difference:
> 
> [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | 
>   1000 timesRepeat: [ 
>   fileStream nextPutAll:
>   (String streamContents: [ :stream |
>   100 timesRepeat: [ stream print: 100 atRandom; 
> space ] ]) ] ] ] timeToRun.
> 159
> 
> Still, the asymmetry is a bit strange.
> Can't the side effects be dealt with using #flush ?
> 
>> There are several stream libraries (for example XTreams) that can easily 
>> support write buffering without the need to care about compatibility.
> 
> Yeah, although the Smalltalk Collection and Stream classes were better than 
> everything else 20, 30 years ago, lots of things have changed and there is 
> lots of competition. The fact that these classes are so nice to use seem to 
> have prevented necessary improvements.


Yes time to move.

> 
> I think I might file this as a Pharo issue.
> 
> Sven
> 
> 

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

[Stéphane Ducasse]

> did you create an issue? 
>> and where did you publish the code? 
> 
> I uploaded them to the PharoInbox, but as I said, only one minor change in 
> SmallDictionary>>remove:  (adding a carrot "^" at the beginning) will fix the 
> discrepancy between the two. But if the consensus is that Dictionary>>remove: 
> and  Dictionary>>remove:ifAbsent: should not be implemented, maybe the same 
> should be true of SmallDictionary as well.

probably.


> Is anyone else bother[ed] by this inconsistency? 
 
 Apparently not. Well, I uploaded two packages to the PharoInbox. One adds 
 #remove: and #remove:ifAbsent: to Dictionary 
 and updates SmallDictionary's implementations of those messages to return 
 the same value 
>>> 
>>> Regardless of what comes of those packages I uploaded, 
>>> SmallDictionary>>remove: and SmallDictionary>>remove:ifAbsent: returning 
>>> two different values is clearly a bug. Looking at it again, I was wrong 
>>> about SmallDictionary>>remove:ifAbsent: returning the key; it does return 
>>> the removed association. Which means at a minimum, SmallDictionary>>remove: 
>>> only needs to have a ^ inserted at its beginning to fix the discrepancy. 
>>> 
 - the association removed - rather than their current behavior of #remove: 
 returning self (no explicit return value) and 
 #remove:ifAbsent: returning the key of the removed association. 
 The second package adds #testRemove and 
 #testRemoveIfAbsent to DictionaryTest (through a trait). 
 
 
 
>>> 
>>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

[Levente Uzonyi]

On Wed, 8 Dec 2010, Philippe Marschall wrote:


On 12/08/2010 12:32 AM, Levente Uzonyi wrote:

On Tue, 7 Dec 2010, Philippe Marschall wrote:

snip


No, buffering should not be in a subclass or even the file stream class
itself. Buffering should be an other class that wraps file stream.


Stream wrappers are cool, but they are totally different from the
current stream design. One could create new stream classes that could do
buffering, conversion, compression, etc. and rewrite existing code to
use them, but if you just rewrite the existing code using an existing
stream library (for example XTreams), then you'll get pretty much the
same thing with less effort.


Nope sorry, writing a stream that buffers is not less effort that
porting and maintaining a whole stream library and rewriting your code.


It would be: writing and maintaining new stream classes VS using an 
existing port.



Levente



Cheers
Philippe

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

[Levente Uzonyi]

On Wed, 8 Dec 2010, Sven Van Caekenberghe wrote:



On 08 Dec 2010, at 00:25, Levente Uzonyi wrote:


Thanks for the explanation, some quick and dirty buffering makes a huge 
difference:

[ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream |
1000 timesRepeat: [
fileStream nextPutAll:
(String streamContents: [ :stream |
100 timesRepeat: [ stream print: 100 atRandom; 
space ] ]) ] ] ] timeToRun.
159

Still, the asymmetry is a bit strange.
Can't the side effects be dealt with using #flush ?


Lets go back in time. A year ago there was no read buffering (Pharo 1.0 was not 
released, Squeak 3.10.2 was out) and reading from a file was as slow as writing 
is currently. Read buffering could be added transparently, so it could give a 
huge speed improvement to all existing code.
Write buffering could be done the same way, but it would break code, because 
currently a write is immediately done, while with buffering it
wouldn't be. Some files would be written only when the finalization process 
closes the file. The solution for this could be automatic flushing on each 
write, which could be turned off by a method. But that would be the same as not 
using write buffering at all.
But with the same effort you could use another stream implementation, that does 
write buffering. And write buffering can't be used to speed up existing code 
without reviewing it.


Thanks again for the explanation.

OK, I tried writing my own buffered write stream class:

[ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | | bufferedStream 
|
bufferedStream := ZnBufferedWriteStream on: fileStream.
10 timesRepeat: [ bufferedStream print: 100 atRandom; space ].
bufferedStream flush ] ] timeToRun.
165

That wasn' too hard. And indeed, it is necessary to manually send #flush or 
#close to force the buffer out.

But I do not completely agree with the fact that it would be that much work. 
Stream>>#flush is already a no-op. Adding it to #streamContents: and some 
others can not be that much work. In fact, SocketStream does already do both input 
and output buffering (and thus requires #flush or #close), so would potentially fail 
in certain situations according to your reasoning. No ?


It would be much work to add the write buffering to StandardFileStream 
(it should also work with MultiByteFileStream) and fix all places in the 
image, that use StandardFileStream or MultiByteFileStream for writing to a 
file.
I don't get how #streamContents: could be used to send #flush. That's a 
method of SequenceableCollection IIRC.
SocketStream is unrelated here, because it doesn't write to files and 
buffering was always implemented in it AFAIK.



Levente



Sven

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Marcus Denker]

On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote:

> 
> On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote:
> 
>> Ok, I've done some fixes to OB and OC, and committed them to PharoTaskForces 
>> as a temporary solution.
>> 
>> To load current configuration:
>> 
>> Gofer it squeaksource: 'MetacelloRepository';
>>   package: 'ConfigurationOfPharo';
>>   load.
>> 
>> (ConfigurationOfPharo project version: '1.2-beta2') load.
>> 
>> Can Hudson help us in building Dev images?
> 
> 
> Yes, will set up a build for 1.2 today.

I have set one up that takes 1.2 core, runs updates and then tries to build dev

https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/

It is failing right now.

https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

[Pharo-project] socket deadlock using Cog VM

[Johan Brichau]

Hi,

We are experiencing a deadlock in Socket>>waitForDataIfClosed:

The problem occurs on Pharo11/Pharo12/Squeak41 only when using the Cog VM.
In our particular case, the socket connects to a GOODS database and it started 
occurring with a growing amount of data (so longer connections, more data 
transfer).

When you open a debugger on the deadlocked process and proceed the process, it 
will simply continue and finish without problems.

We are using Cog VM of 4 october, downloaded from Eliot's website (VM.r2316/)

Before I start isolating the problem and reproduce it without requiring GOODS 
(it's just an http socket anyway): Is anyone else experiencing similar issues 
here? Is there a fix in more recent versions?

cheers
Johan

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

[Sven Van Caekenberghe]

On 08 Dec 2010, at 10:48, Lukas Renggli wrote:

> Very cool framework, I like it a lot! I definitely vote to eventually
> replace HTTPSocket with Zinc HTTP Components.

Thanks a lot, I am glad you like it.

> I wonder why ZnFixedClient is not a subclass of ZnHttpClient?

Well, ZnFixedClient is what I wrote earlier for my needs (I use it inside a 
T3RestJsonClient, then T3CachingRestJsonClient and finally a business specific 
T3Client, works very well). ZnHttpClient is Matt's later version, partially 
inspired by your idea of a builder-style API.

> I think it would be cool to be able to use them polymorphic.

We could maybe use some refactoring, consolidation, redesign (hint, hint). But 
for me, it is also a search for good solutions where I don't think that one 
size will fit all, but I could be wrong (for example, Matt's redirection, 
cookie and more advanced authoritzation support would be nice to have 
everywhere, it is just that I did not need it yet in my applications).

Sven

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

[Philippe Marschall]

On 12/08/2010 12:32 AM, Levente Uzonyi wrote:
> On Tue, 7 Dec 2010, Philippe Marschall wrote:
> 
> snip
> 
>> No, buffering should not be in a subclass or even the file stream class
>> itself. Buffering should be an other class that wraps file stream.
> 
> Stream wrappers are cool, but they are totally different from the
> current stream design. One could create new stream classes that could do
> buffering, conversion, compression, etc. and rewrite existing code to
> use them, but if you just rewrite the existing code using an existing
> stream library (for example XTreams), then you'll get pretty much the
> same thing with less effort.

Nope sorry, writing a stream that buffers is not less effort that
porting and maintaining a whole stream library and rewriting your code.

Cheers
Philippe

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

[Lukas Renggli]

Very cool framework, I like it a lot! I definitely vote to eventually
replace HTTPSocket with Zinc HTTP Components.

I wonder why ZnFixedClient is not a subclass of ZnHttpClient? I think
it would be cool to be able to use them polymorphic.

Lukas


On 8 December 2010 09:26, Sven Van Caekenberghe  wrote:
> Norbert,
>
> Thanks for you interest.
>
> On 07 Dec 2010, at 21:14, Norbert Hartl wrote:
>
>> I scanned the code a few days ago. I tried an initial port to gemstone. 
>> There are quite a few things to do. After discovering that there are really 
>> big changes from version to version and the existence of classes with 
>> suffixes Old and New made me stop the effort. I'm really missing a usable 
>> http client in gemstone but it seemed to be very hard to keep up with the 
>> port.
>
> This should be much better now: the whole confusion is now gone (the 'Old' 
> categories and classes were moved into a separate MC package that should not 
> be loaded unless you want to do historical research; the 'New' has been 
> removed from existing categories). Please have another look.
>
> I assume that you have read the overview and getting started pages 
> (http://homepage.mac.com/svc/Zinc-HTTP-Components).
>
> The category 'Zinc-HTTP-Core' contains a object model of the key building 
> blocks of the HTTP protocol. Except for learning and teaching, this is not 
> useful on itself. Building on top of the core are the classes in 
> 'Zinc-HTTP-Server' for various clients and servers. The category 
> 'Zinc-HTTP-Support' contains helpers for the implementation, many of which 
> can be considered portability enablers (much like Seaside has them).
>
> Now, why is there not just one good client, why are there 4 different ones ?
>
> Because different users have different requirements, because each of them has 
> different features, complexity and above all, a different interface. Part of 
> this is also a search for the ideal API.
>
> ZnClient is the simplest one: some class methods to fire off one shot 
> requests.
>
> ZnFixedClient is useful to connect to a single server and reuse the 
> connection for multiple requests, like with a web services API.
>
> ZnHttpClient is a builder like interface (think of Gofer), it also has some 
> extra features.
>
> ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket 
> API. In my development images, this is active, which means that all HTTP 
> functionality (for MC for example) is handled by Zinc HTTP - a case of eating 
> my own dog food.
>
> On the server side there is ZnServer which can be customized with a delegate 
> and authorizer. A static web file server, a Monticello server as well as a 
> Seaside adaptor are available.
>
>> Do you port an existing library to smalltalk or do you figure out how it 
>> should be done right now? And what do you think about going towards 
>> cross-platform? This would need a decision if you are willing to integrate 
>> grease/sport in your client. I can imagine that this is not wanted per se 
>> because it introduces dependencies. It will be just very hard to do it 
>> cross-platform if you do not.
>
> The first goal of Zinc HTTP is to be useful for Pharo, to replace existing 
> HTTP functionality in the image. Hence portability is not high on the list. 
> Like you said, building on top of a portability layer would mean external 
> dependencies that would most probably conflict with the first goal. But I am 
> not against portability (most of the code except for some obvious missing 
> crypto stuff still runs on Squeak as well). We can always try to find a 
> solution.
>
> Regards,
>
> Sven
>
>
>



-- 
Lukas Renggli
www.lukas-renggli.ch

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

[Sven Van Caekenberghe]

On 08 Dec 2010, at 00:25, Levente Uzonyi wrote:

>> Thanks for the explanation, some quick and dirty buffering makes a huge 
>> difference:
>> 
>> [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream |
>>  1000 timesRepeat: [
>>  fileStream nextPutAll:
>>  (String streamContents: [ :stream |
>>  100 timesRepeat: [ stream print: 100 atRandom; 
>> space ] ]) ] ] ] timeToRun.
>> 159
>> 
>> Still, the asymmetry is a bit strange.
>> Can't the side effects be dealt with using #flush ?
> 
> Lets go back in time. A year ago there was no read buffering (Pharo 1.0 was 
> not released, Squeak 3.10.2 was out) and reading from a file was as slow as 
> writing is currently. Read buffering could be added transparently, so it 
> could give a huge speed improvement to all existing code.
> Write buffering could be done the same way, but it would break code, because 
> currently a write is immediately done, while with buffering it
> wouldn't be. Some files would be written only when the finalization process 
> closes the file. The solution for this could be automatic flushing on each 
> write, which could be turned off by a method. But that would be the same as 
> not using write buffering at all.
> But with the same effort you could use another stream implementation, that 
> does write buffering. And write buffering can't be used to speed up existing 
> code without reviewing it.

Thanks again for the explanation.

OK, I tried writing my own buffered write stream class:

[ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | | bufferedStream 
|
bufferedStream := ZnBufferedWriteStream on: fileStream.
10 timesRepeat: [ bufferedStream print: 100 atRandom; space ].
bufferedStream flush ] ] timeToRun.
165

That wasn' too hard. And indeed, it is necessary to manually send #flush or 
#close to force the buffer out.

But I do not completely agree with the fact that it would be that much work. 
Stream>>#flush is already a no-op. Adding it to #streamContents: and some 
others can not be that much work. In fact, SocketStream does already do both 
input and output buffering (and thus requires #flush or #close), so would 
potentially fail in certain situations according to your reasoning. No ?

Sven

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

[Marcus Denker]

On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote:

> Ok, I've done some fixes to OB and OC, and committed them to PharoTaskForces 
> as a temporary solution.
> 
> To load current configuration:
> 
> Gofer it squeaksource: 'MetacelloRepository';
>   package: 'ConfigurationOfPharo';
>   load.
> 
> (ConfigurationOfPharo project version: '1.2-beta2') load.
> 
> Can Hudson help us in building Dev images?


Yes, will set up a build for 1.2 today.

Marcus


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] Hudson and version number

[Luc Fabresse]

I guess it was the latest version.
Yes it would be good to integrate the version number to retrieve it after.
Thanks for the info.

#Luc


2010/12/8 Adrian Lienhard 

> That's how I did it:
>
> Install the "Hudson description setter plugin" [1]
>
> From Pharo, when you do the build and know the last build number, log this
> version to stdout (e.g., "[version] 1.2 #12421").
>
> In the job config enable "Set build description" and add the following
> settings:
> - Set build description: "\[version\] (.*)"
> - Description: "\1"
>
> [1] http://wiki.hudson-ci.org/display/HUDSON/Description+Setter+Plugin
>
> Like this you get a description below each build as shown in the attached
> screenshot.
>
> Cheers,
> Adrian
>
>
>
>
>
> On Dec 8, 2010, at 09:39 , Marcus Denker wrote:
>
> >
> > On Dec 8, 2010, at 9:35 AM, Marcus Denker wrote:
> >
> >>
> >> On Dec 8, 2010, at 8:25 AM, Luc Fabresse wrote:
> >>
> >>> Hi all,
> >>>
> >>> I was looking the results of the 1.2 build #33.
> >>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/
> >>>
> >>> Where is displayed the version number of the 1.2 used for this build?
> >>> Was it the12271?
> >>>
> >>>
> >> I always loads all updates... so it's the version that was available at
> the time
> >> of build. It would be nice to display the update number... if anyone has
> an
> >> idea how to do that?
> >>
> > And I forgot: after an update is commited, the build starts automatically
> within
> > 2 minutes. So in the end this means: the latest build on Hudson is the
> latest
> > update available.
> >
> >   Marcus
> >
> >
> >
> > --
> > Marcus Denker  -- http://www.marcusdenker.de
> > INRIA Lille -- Nord Europe. Team RMoD.
> >
>
>
>

Re: [Pharo-project] Hudson and version number

[Adrian Lienhard]

That's how I did it:

Install the "Hudson description setter plugin" [1]

From Pharo, when you do the build and know the last build number, log this 
version to stdout (e.g., "[version] 1.2 #12421").

In the job config enable "Set build description" and add the following 
settings: 
- Set build description: "\[version\] (.*)"
- Description: "\1"

[1] http://wiki.hudson-ci.org/display/HUDSON/Description+Setter+Plugin

Like this you get a description below each build as shown in the attached 
screenshot.

Cheers,
Adrian


<>

On Dec 8, 2010, at 09:39 , Marcus Denker wrote:

> 
> On Dec 8, 2010, at 9:35 AM, Marcus Denker wrote:
> 
>> 
>> On Dec 8, 2010, at 8:25 AM, Luc Fabresse wrote:
>> 
>>> Hi all,
>>> 
>>> I was looking the results of the 1.2 build #33.
>>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/
>>> 
>>> Where is displayed the version number of the 1.2 used for this build? 
>>> Was it the12271?
>>> 
>>> 
>> I always loads all updates... so it's the version that was available at the 
>> time
>> of build. It would be nice to display the update number... if anyone has an
>> idea how to do that?
>> 
> And I forgot: after an update is commited, the build starts automatically 
> within
> 2 minutes. So in the end this means: the latest build on Hudson is the latest
> update available.
> 
>   Marcus
> 
> 
> 
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
> 

Re: [Pharo-project] Problem updating Pharo Core

[Marcus Denker]

On Dec 7, 2010, at 12:17 PM, Gary Chambers wrote:

> Does the build server run Windows? (c.f. $: in package name).
> 

No, we have right now just a Linux builder. But we will add Mac soon,
after that windows.

> Regards, Gary
> - Original Message -
> From: Marcus Denker
> To: Pharo-project@lists.gforge.inria.fr
> Sent: Monday, December 06, 2010 9:11 PM
> Subject: Re: [Pharo-project] Problem updating Pharo Core
> 
> 
> On Dec 6, 2010, at 7:59 PM, Guillermo Polito wrote:
> 
>> I have the last prebuild pharo core (12261), and clicking on update stops in 
>> version 12266 with a DNU:
>> 
>> nil does not understand binary
>> 
>> It has something to do with the monticello a version with this info:  'Issue 
>> 3191:SparseLargeArray-MarcusDenker.2.mcz'
>> 
>> Did someone had this same issue?
>> 
> 
> the build server seems to have no problem:
> 
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/
> 
> 
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
> 
> 

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] Hudson and version number

[Marcus Denker]

On Dec 8, 2010, at 9:35 AM, Marcus Denker wrote:

> 
> On Dec 8, 2010, at 8:25 AM, Luc Fabresse wrote:
> 
>> Hi all,
>> 
>>  I was looking the results of the 1.2 build #33.
>>  https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/
>> 
>>  Where is displayed the version number of the 1.2 used for this build? 
>>  Was it the12271?
>> 
>> 
> I always loads all updates... so it's the version that was available at the 
> time
> of build. It would be nice to display the update number... if anyone has an
> idea how to do that?
> 
And I forgot: after an update is commited, the build starts automatically within
2 minutes. So in the end this means: the latest build on Hudson is the latest
update available.

Marcus



--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] Hudson and version number

[Marcus Denker]

On Dec 8, 2010, at 8:25 AM, Luc Fabresse wrote:

> Hi all,
> 
>  I was looking the results of the 1.2 build #33.
>  https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/
> 
>  Where is displayed the version number of the 1.2 used for this build? 
>  Was it the12271?
> 
> 
I always loads all updates... so it's the version that was available at the time
of build. It would be nice to display the update number... if anyone has an
idea how to do that?



--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

[Sven Van Caekenberghe]

Norbert,

Thanks for you interest.

On 07 Dec 2010, at 21:14, Norbert Hartl wrote:

> I scanned the code a few days ago. I tried an initial port to gemstone. There 
> are quite a few things to do. After discovering that there are really big 
> changes from version to version and the existence of classes with suffixes 
> Old and New made me stop the effort. I'm really missing a usable http client 
> in gemstone but it seemed to be very hard to keep up with the port.

This should be much better now: the whole confusion is now gone (the 'Old' 
categories and classes were moved into a separate MC package that should not be 
loaded unless you want to do historical research; the 'New' has been removed 
from existing categories). Please have another look.

I assume that you have read the overview and getting started pages 
(http://homepage.mac.com/svc/Zinc-HTTP-Components). 

The category 'Zinc-HTTP-Core' contains a object model of the key building 
blocks of the HTTP protocol. Except for learning and teaching, this is not 
useful on itself. Building on top of the core are the classes in 
'Zinc-HTTP-Server' for various clients and servers. The category 
'Zinc-HTTP-Support' contains helpers for the implementation, many of which can 
be considered portability enablers (much like Seaside has them).

Now, why is there not just one good client, why are there 4 different ones ?

Because different users have different requirements, because each of them has 
different features, complexity and above all, a different interface. Part of 
this is also a search for the ideal API.

ZnClient is the simplest one: some class methods to fire off one shot requests.

ZnFixedClient is useful to connect to a single server and reuse the connection 
for multiple requests, like with a web services API.

ZnHttpClient is a builder like interface (think of Gofer), it also has some 
extra features.

ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket 
API. In my development images, this is active, which means that all HTTP 
functionality (for MC for example) is handled by Zinc HTTP - a case of eating 
my own dog food.

On the server side there is ZnServer which can be customized with a delegate 
and authorizer. A static web file server, a Monticello server as well as a 
Seaside adaptor are available.

> Do you port an existing library to smalltalk or do you figure out how it 
> should be done right now? And what do you think about going towards 
> cross-platform? This would need a decision if you are willing to integrate 
> grease/sport in your client. I can imagine that this is not wanted per se 
> because it introduces dependencies. It will be just very hard to do it 
> cross-platform if you do not.

The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP 
functionality in the image. Hence portability is not high on the list. Like you 
said, building on top of a portability layer would mean external dependencies 
that would most probably conflict with the first goal. But I am not against 
portability (most of the code except for some obvious missing crypto stuff 
still runs on Squeak as well). We can always try to find a solution. 

Regards,

Sven