Re: [ANN] Shootout benchmarking copied to ss3

Maybe you should do a package with all the benchmarks available for Smalltalk ?

On Sun, Apr 1, 2012 at 12:06 AM, Nicolas Cellier
<nicolas.cellier.aka.nice@...> wrote:
> These benchmarks are good, so I took the port of Eliot from Cog VMMaker and
> made a package of its own.
> Since I cannot create a new project on squeaksource, I decided to try SS3.
>
> See
> http://ss3.gemstone.com/ss/Shootout.html/
> http://ss3.gemstone.com/ss/Shootout.html/Wiki
> http://shootout.alioth.debian.org/u32/benchmark.php
>
> Nicolas

--

-- 
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

Re: Collection new printString make the image hanging

Re: Windows Installer (was: direct object manipulation)

On Apr 1, 2012, at 12:07 AM, Torsten Bergmann wrote:

>> Yes, and for consistency. Either we go "installer for all three platforms",
>> or not. Having a one-click for all but windows in addition ist just >confusing.
> 
> People often provide ZIP or TARs in open source projects for non-Windows 
> and special windows installers for M$ users. Its not uncommmon.
> So the user can choose which one he wants to use.
> 
Yes. So now that are two option:
	-> Delay everything until we have that.
	-> Not Delay everything.

I am always for "Doing while Doing".... and this means:

	-> Finish the one-click build script and activate it for 1.3 and 1.4

This is not a lot of work, and then we hat *at least* what we had until know, fully auto-build
and up to date. *After* that we can improve. But only after that.

And there are lots of things on the list...

	-> fix the failing test in 1.3Full
	-> fix the remaining 1.4 bugs
	-> do the 1.4 release
	-> run tests on windows besided mac and linux
	-> actually run all tests *before* triggering the build of all depending projects
	-> integrate SSL
	-> merge nativeboost VM with man VM
	-> install Android Dev tools
	-> configure Android build
	-> Look at ARM build of interpreter

The good news is that we got a bit more manpower lately... 

>> Does it make sense to have a download of 1.2 on the download page?
> 
> Maybe I'm blind - but on the download page for the 1.2 version - YES:
> 
Nobody should download 1.2... it's there just for historical reasons.

	Marcus

--
Marcus Denker -- http://marcusdenker.de

Re: Windows Installer (was: direct object manipulation)

Torsten, i remember about it.
We had problems with windows slave when migrated from Hudson to Jenkins.
Now they are gone.. so we can finish what is planned.

On 31 March 2012 22:42, Torsten Bergmann <astares@...> wrote:
>>> I want a good installer for each platform :)
>>>
>>For newspeak there is a native installer for Mac OS and Windows.
>
> We already have/had a native Installer for Pharo on Windows.
>
> I already posted the script and resources for the free NSIS installer
> already on the list and also gave it to Igor.
>
> I've built them manually in the past. The idea was that the Jenkins
> Windows Slave should automatically build the setup. Looks like this
> is not yet done - maybe for time reasons. I wonder why they are
> removed from the homepages download section?
>
> However - one can still access the setup exe files at the inria files
> section [2] under "Pharo Win32 Setup".
>
> I still think that such an installer (which is standard on windows)
> is helpful for better adoption.
>
> Bye
> T.
>
>
> [1] http://www.mail-archive.com/pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0 <at> public.gmane.org/msg09522.html
>
> [2] https://gforge.inria.fr/frs/?group_id=1299&release_id=5962#pharo-win32-setup-_1.2.1.-title-content
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>

--

-- 
Best regards,
Igor Stasenko.

Re: Windows Installer (was: direct object manipulation)

you have the one click on this page

On Apr 1, 2012, at 12:07 AM, Torsten Bergmann wrote:

>> Yes, and for consistency. Either we go "installer for all three platforms",
>> or not. Having a one-click for all but windows in addition ist just >confusing.
> 
> People often provide ZIP or TARs in open source projects for non-Windows 
> and special windows installers for M$ users. Its not uncommmon.
> So the user can choose which one he wants to use.
> 
> It will only be confusing if an image in a x.y one click version of Pharo
> is different than in a Win32 setup with the same version. But this should
> be solved when all is based on the same Jenkins-built image as common source.
> 
> There are good installers for all major platforms - but only commercial.
> Dont know about free installer projects for non-Windows platforms.
> 
> Why not provide an installer depend on the environment and which one
> the user expects:
> For Linux I think an "apt-get pharo" would be suited similar to Squeak
> and for Windows a wizard guided installer.
> 
>> Does it make sense to have a download of 1.2 on the download page?
> 
> Maybe I'm blind - but on the download page for the 1.2 version - YES:
> 
> http://www.pharo-project.org/pharo-download/release-1-2
> 
> Bye
> T.
> 
> -- 
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> 

Re: Windows Installer (was: direct object manipulation)

On Apr 1, 2012, at 9:02 AM, Marcus Denker wrote:

> 
> On Apr 1, 2012, at 12:07 AM, Torsten Bergmann wrote:
> 
>>> Yes, and for consistency. Either we go "installer for all three platforms",
>>> or not. Having a one-click for all but windows in addition ist just >confusing.
>> 
>> People often provide ZIP or TARs in open source projects for non-Windows 
>> and special windows installers for M$ users. Its not uncommmon.
>> So the user can choose which one he wants to use.
>> 
> Yes. So now that are two option:
> 	-> Delay everything until we have that.
> 	-> Not Delay everything.
> 
> I am always for "Doing while Doing".... and this means:
> 
> 	-> Finish the one-click build script and activate it for 1.3 and 1.4

+ 1000000 :)

> This is not a lot of work, and then we hat *at least* what we had until know, fully auto-build
> and up to date. *After* that we can improve. But only after that.

Yes 
> 
> And there are lots of things on the list...
> 
> 	-> fix the failing test in 1.3Full
> 	-> fix the remaining 1.4 bugs
> 	-> do the 1.4 release
> 	-> run tests on windows besided mac and linux
> 	-> actually run all tests *before* triggering the build of all depending projects
> 	-> integrate SSL
> 	-> merge nativeboost VM with man VM
> 	-> install Android Dev tools
> 	-> configure Android build
> 	-> Look at ARM build of interpreter
> 
> The good news is that we got a bit more manpower lately... 
> 
> 
>>> Does it make sense to have a download of 1.2 on the download page?
>> 
>> Maybe I'm blind - but on the download page for the 1.2 version - YES:
>> 
> Nobody should download 1.2... it's there just for historical reasons.
> 
> 	Marcus
> 
> --
> Marcus Denker -- http://marcusdenker.de
> 
> 

PluggableTextMorph changed behavior

Hello,

As far as PluggableTextMorph can be understandable, I used the code
bellow to 'manipulate' text field the user can edit.
The code bellow was working recently:

	morph := PluggableTextMorph
		on: builder text: #title accept: #title:.
	morph acceptTextInModel.
	morph
		color: Color white;
		acceptOnCR: true;
		hResizing: #spaceFill;
		height: 16;
		hideScrollBarsIndefinitely.

When user edit text, the model (builder) was updated.
Now not anymore with recent 1.4.

What's wrong?

Hilaire

--

-- 
Dr. Geo -- http://www.drgeo.eu

Re: PluggableTextMorph changed behavior

Le 01/04/2012 14:29, Hilaire Fernandes a écrit :
> Hello,
> 
> As far as PluggableTextMorph can be understandable, I used the code
> bellow to 'manipulate' text field the user can edit.
> The code bellow was working recently:
> 
> 	morph := PluggableTextMorph
> 		on: builder text: #title accept: #title:.
> 	morph acceptTextInModel.
> 	morph
> 		color: Color white;
> 		acceptOnCR: true;

Changing to

	autoAccept: true;

get it work.

We should have a way to track and document the changes we make in the image.

--

-- 
Dr. Geo -- http://www.drgeo.eu

Re: PluggableTextMorph changed behavior

Well the problem is that Morph is so complex and the API totally obscure.
Last time we spent 2 hours to find that the ghost text did not work because of not initialized correctly
somewhere else.
So we should slowly clean the API. 
Now for this change I have no idea. What you should see is that there was a lot of work to bring a new and better text.

Stef

On Apr 1, 2012, at 2:40 PM, Hilaire Fernandes wrote:

> Le 01/04/2012 14:29, Hilaire Fernandes a écrit :
>> Hello,
>> 
>> As far as PluggableTextMorph can be understandable, I used the code
>> bellow to 'manipulate' text field the user can edit.
>> The code bellow was working recently:
>> 
>> 	morph := PluggableTextMorph
>> 		on: builder text: #title accept: #title:.
>> 	morph acceptTextInModel.
>> 	morph
>> 		color: Color white;
>> 		acceptOnCR: true;
> 
> Changing to
> 
> 	autoAccept: true;
> 
> 
> get it work.
> 
> 
> We should have a way to track and document the changes we make in the image.
> 
> 
> 
> -- 
> Dr. Geo -- http://www.drgeo.eu
> 
> 

Re: PluggableTextMorph changed behavior

On 4/1/12 5:40 AM, Hilaire Fernandes wrote:
[...]
> We should have a way to track and document the changes we make in the 
> image. 

Spoon will have a very fine-grained solution for this issue.

L