Hi Mariano, Is the 1.1.1 dev image available for the old VM? I was a bit away, and I am not sure of the status. If there is something I can do, please let me know. Cheers, Doru On 25 Sep 2010, at 19:49, Mariano Martinez Peck wrote:

On Sat, Sep 25, 2010 at 7:09 PM, Tudor Girba <tudor.girba@gmail.com> wrote: Hi Mariano,

This is a good and needed step.

Now, just a problem: 1.1.1dev image does not work with the regular VM. This is probably because you saved it again after you opened it with the Cog VM. It would be great if the released dev image would work with both.

Excellent suggestion :) Thanks doru.

Cheers, Doru

On 25 Sep 2010, at 17:56, Mariano Martinez Peck wrote:

...

Hi. This is not an official release. I didn't do all the formal procedure for releasing a Pharo image. My idea is try to push CogVM and try to get as much as testers as possible. Try to report issues and help Eliot. For that purpose, I think having a one click image is worth it.

So.....I build a Pharo dev on top of the PharoCore 1.1.1 (which has some fixes over 1.1 and the CogVM necessary changes). I build the image with exactly the same versions of the external packages than Pharo 1.1.

If you want to download that this Pharo1.1.1 dev image that works with Cog here is the link:

https://gforge.inria.fr/frs/download.php/27516/Pharo-1.1.1-dev10.09.1.zip

In addition, and thanks to Lukas, we could generate OneClicks with CogVM. Here you can have a OneClick using the above image:

https://gforge.inria.fr/frs/download.php/27524/Pharo-1.1.1-OneClickCogVM.zip

Notice that this is not an official release and that there are failing/errors tests. I've already sent emails for them and hopefully someone may fix them. The only thing is not supported is the TestCoverage (since it uses objects as methods, with is not yet supported in CogVM).

Cheers

Mariano _______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

-- www.tudorgirba.com

"The coherence of a trip is given by the clearness of the goal."

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

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

-- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

2 years, we're plagued by this for two years! On 30 September 2010 15:14, laurent laffont <laurent.laffont@gmail.com> wrote:

On up to date ArchLinux, 32 bits. 1. Open One Click 2. Open MonticelloBrowser 3. Save a packages (Tests for ex.) in package cache 4. Dialog to enter commit message opens, click ok 5. crash It reminds me about the UUID plugin as external problem. It should be built as internal. $ sh Pharo.sh Segmentation fault

Smalltalk stack dump: 0xbfa9f80c I UUID>initialize 2023565392: a(n) UUID 0xbfa9f824 M UUID class(Behavior)>new: 2000732936: a(n) UUID class 0xbfa9f848 I UUID class>new 2000732936: a(n) UUID class -- Best regards, Igor Stasenko AKA sig.

2010/9/30 Sven Van Caekenberghe <sven@beta9.be>:

Less plugins, more Smalltalk code! I want to look at everything and never see C. Plugins/primitives should only be there when they are absolutely necessary (to access a platform feature or for crucial performance).

Sven

+1

For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Sunday, October 03, 2010 4:57 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm) On 30 sept. 2010, at 20:22, Germán Arduino wrote:

2010/9/30 Sven Van Caekenberghe <sven@beta9.be>:

...

Less plugins, more Smalltalk code! I want to look at everything and never see C. Plugins/primitives should only be there when they are absolutely necessary (to access a platform feature or for crucial performance).

Sven

+1

Yes. This is the approach we advocate in the Ocean project. We would like to see it generalized beyond the network library. Noury _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Noury, I am very interested in seeing this done well. At a minimum, I'll give the result some serious abuse. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Monday, October 04, 2010 4:59 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)) On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote:

For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening.

You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-) BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations. Noury _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Noury, One of the other aspects that I find important is elementary efficiency. A lot of stream related code in Smalltalk is not efficient, the actual data is copied around like crazy, turning it from a stream to a collection and then back into a stream multiple times. For Zinc HTTP Components I made a lot of effort to make it possible to read data from a socket stream in true streaming fashion (instead of just returning a byte array). Now, the idea was then that for example JPEGReadWriter>>#nextImage would work transparaently on that raw stream. Sadly, the code in JPEGReadWriter and friends just reads everything into an array before it starts to work ! Doing a #nextPutAll: <some byte array> should really try never to copy the array. Similary, a #next: <count> into: <some byte array> should similary write directly into the given array. What I see in the current SocketStream is <censored/> ;-) But OK, maybe this is easier said than done. The step from Smalltalk to system call should also not copy if that is possible, but then FFI and GC come into play. Anyway, good luck, I am willing to try using Ocean as soon as it becomes available. Sven On 04 Oct 2010, at 10:59, Noury Bouraqadi wrote:

On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote:

...

For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening.

You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-)

BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations.

Noury

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

On Mon, 4 Oct 2010, Sven Van Caekenberghe wrote:

Noury,

One of the other aspects that I find important is elementary efficiency.

A lot of stream related code in Smalltalk is not efficient, the actual data is copied around like crazy, turning it from a stream to a collection and then back into a stream multiple times. For Zinc HTTP Components I made a lot of effort to make it possible to read data from a socket stream in true streaming fashion (instead of just returning a byte array). Now, the idea was then that for example JPEGReadWriter>>#nextImage would work transparaently on that raw stream. Sadly, the code in JPEGReadWriter and friends just reads everything into an array before it starts to work !

Doing a #nextPutAll: <some byte array> should really try never to copy the array. Similary, a #next: <count> into: <some byte array> should similary write directly into the given array. What I see in the current SocketStream is <censored/> ;-)

This is why we implemented our own SocketStream in PostgresV3.

But OK, maybe this is easier said than done. The step from Smalltalk to system call should also not copy if that is possible, but then FFI and GC come into play.

I wonder if there's a language, that provides socket access via FFI. Levente

Anyway, good luck, I am willing to try using Ocean as soon as it becomes available.

Sven

On 04 Oct 2010, at 10:59, Noury Bouraqadi wrote:

...

On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote:

...

For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening.

You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-)

BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations.

Noury

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

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

Sig, Yes and no. OS threads can get expensive, and some (admittedly dated) literature shows an edge for asynchronous sockets and green threads over OS threads. That said, the blocking call+OS thread model is a lot easier to understand than are non-block calls, *especially* for OpenSSL. On balance I agree that it would be a good thing for us to do, not necessarily that it is the preferred course in general. So let's say we go for the (in Dolphin speak) overlapped calls. Does NativeBoost do them now? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Monday, October 04, 2010 5:24 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)) I think that this project would be good test-bed for testing a non-blocking FFI callouts. On 4 October 2010 23:23, Levente Uzonyi <leves@elte.hu> wrote:

On Mon, 4 Oct 2010, Sven Van Caekenberghe wrote:

...

Noury,

One of the other aspects that I find important is elementary efficiency.

A lot of stream related code in Smalltalk is not efficient, the actual data is copied around like crazy, turning it from a stream to a collection and then back into a stream multiple times. For Zinc HTTP Components I made a lot of effort to make it possible to read data from a socket stream in true streaming fashion (instead of just returning a byte array). Now, the idea was then that for example JPEGReadWriter>>#nextImage would work transparaently on that raw stream. Sadly, the code in JPEGReadWriter and friends just reads everything into an array before it starts to work !

Doing a #nextPutAll: <some byte array> should really try never to copy the array. Similary, a #next: <count> into: <some byte array> should similary write directly into the given array. What I see in the current SocketStream is <censored/> ;-)

This is why we implemented our own SocketStream in PostgresV3.

...

But OK, maybe this is easier said than done. The step from Smalltalk to system call should also not copy if that is possible, but then FFI and GC come into play.

I wonder if there's a language, that provides socket access via FFI.

Levente

...

Anyway, good luck, I am willing to try using Ocean as soon as it becomes available.

Sven

On 04 Oct 2010, at 10:59, Noury Bouraqadi wrote:

...

On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote:

...

For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening.

You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-)

BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations.

Noury

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

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

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

-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Thu, 30 Sep 2010, laurent laffont wrote:

On up to date ArchLinux, 32 bits.

1. Open One Click 2. Open MonticelloBrowser 3. Save a packages (Tests for ex.) in package cache 4. Dialog to enter commit message opens, click ok 5. crash

It reminds me about the UUID plugin as external problem. It should be built as internal.

No, it shouldn't. It immediately crashes, if libuuid is not available, which happens to be the case on some 64-bit version of Debian and Ubuntu. Levente

$ sh Pharo.sh

Segmentation fault

Smalltalk stack dump: 0xbfa9f80c I UUID>initialize 2023565392: a(n) UUID 0xbfa9f824 M UUID class(Behavior)>new: 2000732936: a(n) UUID class 0xbfa9f848 I UUID class>new 2000732936: a(n) UUID class 0xbfa9f870 I MCWorkingAncestry>infoWithName:message: 2006007052: a(n) MCWorkingAncestry 0xbfa9f8a0 I MCWorkingCopy>newVersionWithName:message: 2001405256: a(n) MCWorkingCopy 0xbfa9f8cc I MCWorkingCopy>newVersion 2001405256: a(n) MCWorkingCopy 0xbfa9f8ec M MCWorkingCopyBrowser>saveVersion 2022465908: a(n) MCWorkingCopyBrowser 0xbfa9f90c I PluggableButtonMorphPlus(PluggableButtonMorph)>performAction 2022486348: a(n) PluggableButtonMorphPlus 0xbfa9f92c I PluggableButtonMorphPlus>performAction 2022486348: a(n) PluggableButtonMorphPlus 0xbfa9f948 M [] in PluggableButtonMorphPlus(PluggableButtonMorph)>mouseUp: 2022486348: a(n) PluggableButtonMorphPlus 0xbfa9f96c M Array(SequenceableCollection)>do: 2022623240: a(n) Array 0xbfa9f994 I PluggableButtonMorphPlus(PluggableButtonMorph)>mouseUp: 2022486348: a(n) PluggableButtonMorphPlus 0xbfa9f9b8 I PluggableButtonMorphPlus>mouseUp: 2022486348: a(n) PluggableButtonMorphPlus 0xbfa9f9d4 M PluggableButtonMorphPlus(Morph)>handleMouseUp: 2022486348: a(n) PluggableButtonMorphPlus 0xbfa9f9f0 M MouseButtonEvent>sentTo: 2022623200: a(n) MouseButtonEvent 0xbfa9fa0c M PluggableButtonMorphPlus(Morph)>handleEvent: 2022486348: a(n) PluggableButtonMorphPlus 0xbfa9fa28 M PluggableButtonMorphPlus(Morph)>handleFocusEvent: 2022486348: a(n) PluggableButtonMorphPlus 0xbfa9fa50 M [] in HandMorph>sendFocusEvent:to:clear: 2001235900: a(n) HandMorph 0xbfa9fa6c M [] in PasteUpMorph>becomeActiveDuring: 2001524352: a(n) PasteUpMorph 0xbfa9fa88 M BlockClosure>on:do: 2022623148: a(n) BlockClosure 0xbfa9fab4 M PasteUpMorph>becomeActiveDuring: 2001524352: a(n) PasteUpMorph 0xbfa9fad8 M HandMorph>sendFocusEvent:to:clear: 2001235900: a(n) HandMorph 0xbfa9fb00 M HandMorph>sendEvent:focus:clear: 2001235900: a(n) HandMorph 0xbfa9fb24 M HandMorph>sendMouseEvent: 2001235900: a(n) HandMorph 0xbfa9fb48 M HandMorph>handleEvent: 2001235900: a(n) HandMorph 0xbfa9fb74 M HandMorph>processEvents 2001235900: a(n) HandMorph 0xbfa9fb8c M [] in WorldState>doOneCycleNowFor: 2002154700: a(n) WorldState 0xbfa9fbb0 M Array(SequenceableCollection)>do: 1999805528: a(n) Array 0xbfa9fbcc M WorldState>handsDo: 2002154700: a(n) WorldState 0xbfa9fbe8 M WorldState>doOneCycleNowFor: 2002154700: a(n) WorldState 0xbfa9fc04 M WorldState>doOneCycleFor: 2002154700: a(n) WorldState 0xbfa9fc20 M PasteUpMorph>doOneCycle 2001524352: a(n) PasteUpMorph 0xbfa9fc40 I [] in Project class>? 2002234208: a(n) Project class 2001355268 s [] in BlockClosure>?

Most recent primitives truncated fractionPart truncated basicNew truncated basicNew truncated fractionPart fractionPart truncated fractionPart truncated fractionPart truncated basicNew truncated perform:with: perform:with: basicNew truncated @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ basicNew @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ copyBits @ @ basicNew at:put: basicNew new: at:put: species basicNew new: species basicNew new: species basicNew new: at:put: at:put: species basicNew new: @ @ basicNew at:put: @ @ basicNew at:put: species species species species species species replaceFrom:to:with:startingAt: at:put: new: at:put: at:put: @ @ basicNew shallowCopy shallowCopy basicNew new: at:put: shallowCopy new: replaceFrom:to:with:startingAt: at:put: shallowCopy basicNew basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ @ basicNew at:put: @ @ basicNew shallowCopy shallowCopy basicNew new: at:put: shallowCopy new: replaceFrom:to:with:startingAt: at:put: shallowCopy basicNew basicNew @ @ basicNew at:put: @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ copyBits @ @ basicNew at:put: basicNew new: species basicNew new: species basicNew new: at:put: at:put: at:put: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: millisecondClockValue signal primSignal:atMilliseconds: millisecondClockValue wait primGetNextEvent: millisecondClockValue wait signal millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait primShowRectLeft:right:top:bottom: primitiveDeferUpdates: forceDisplayUpdate findNextUnwindContextUpTo: terminateTo: basicNew: primMakeUUID Abandon

Laurent Laffont

Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

On Thu, Sep 30, 2010 at 1:44 PM, Tudor Girba <tudor.girba@gmail.com> wrote:

...

Hi Mariano,

Is the 1.1.1 dev image available for the old VM?

I was a bit away, and I am not sure of the status. If there is something I can do, please let me know.

Cheers, Doru

On 25 Sep 2010, at 19:49, Mariano Martinez Peck wrote:

...

On Sat, Sep 25, 2010 at 7:09 PM, Tudor Girba <tudor.girba@gmail.com>

wrote:

...

Hi Mariano,

This is a good and needed step.

Now, just a problem: 1.1.1dev image does not work with the regular VM. This is probably because you saved it again after you opened it with the Cog VM. It would be great if the released dev image would work with both.

Excellent suggestion :) Thanks doru.

Cheers, Doru

On 25 Sep 2010, at 17:56, Mariano Martinez Peck wrote:

...

Hi. This is not an official release. I didn't do all the formal procedure for releasing a Pharo image. My idea is try to push CogVM and try to get as much as testers as possible. Try to report issues and help Eliot. For that purpose, I think having a one click image is worth it.

So.....I build a Pharo dev on top of the PharoCore 1.1.1 (which has some fixes over 1.1 and the CogVM necessary changes). I build the image with exactly the same versions of the external packages than Pharo 1.1.

If you want to download that this Pharo1.1.1 dev image that works with Cog here is the link:

https://gforge.inria.fr/frs/download.php/27516/Pharo-1.1.1-dev10.09.1.zip

...

In addition, and thanks to Lukas, we could generate OneClicks with

CogVM. Here you can have a OneClick using the above image:

...

https://gforge.inria.fr/frs/download.php/27524/Pharo-1.1.1-OneClickCogVM.zip

...

Notice that this is not an official release and that there are

failing/errors tests. I've already sent emails for them and hopefully someone may fix them. The only thing is not supported is the TestCoverage (since it uses objects as methods, with is not yet supported in CogVM).

...

Cheers

Mariano _______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

-- www.tudorgirba.com

"The coherence of a trip is given by the clearness of the goal."

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

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

-- www.tudorgirba.com

"In a world where everything is moving ever faster, one might have better chances to win by moving slower."

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

Forgot this mail, now found the other thread talking about this.....Sorry. 2010/10/13 Germán Arduino <garduino@gmail.com>:

This is what is happening here with Ubuntu 10.04, but I've libuuid1 installed.

What I should do to use Cog ?

Thanks.

2010/9/30 Levente Uzonyi <leves@elte.hu>:

...

On Thu, 30 Sep 2010, laurent laffont wrote:

...

On up to date ArchLinux, 32 bits.

1. Open One Click 2. Open MonticelloBrowser 3. Save a packages (Tests for ex.) in package cache 4. Dialog to enter commit message opens, click ok 5. crash

It reminds me about the UUID plugin as external problem. It should be built as internal.

No, it shouldn't. It immediately crashes, if libuuid is not available, which happens to be the case on some 64-bit version of Debian and Ubuntu.

Levente

-- ================================================= Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino Arduino Software & Web Hosting   http://www.arduinosoftware.com PasswordsPro  http://www.passwordspro.com =================================================