Re: [Pharo-project] Pharo wiki?

[Mariano Martinez Peck]

On Fri, Nov 9, 2012 at 1:33 AM, Sebastian Nozzi  wrote:

> Hello Pharo Community,
>
> are there plans to host a Pharo wiki somewhere?
>
> (for tutorials, tips, faqs, documentation, ideas, brainstorming, etc.)
>
>
We have this: http://book.pharo-project.org/


> Cheers,
>
> Sebastian
>
>


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

Re: [Pharo-project] NB Capabilities

[Igor Stasenko]

On 8 November 2012 23:25, Jimmie Houchin  wrote:
>
> On a second look at the API's documentation, the DLL is C++ not C. I don't
> know, but that might have been evident by the requirement of implementing
> interfaces.
>
well, with C++ it is a bit worse than C: because C++ compilers use
name mangling for the function names.
Means that, if you will look for exported function 'abc()', you will
probably find it under different name, like
abc@nby_xrt

apart from that, once you figure the exact correct name, you can go
and call that function.

Things is a bit different if the exported function is a member of class.

So, what i can say.. you can try and see if it rolls (or rocks).. and
if it not, then the best option would be to implement own wrapper
library (but this time in C). And then use that library from pharo.

> I thought I would provide that information, just in case in has a big
> bearing NB/Pharo's ability and on my learning curve.
>
> Jimmie
>



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-project] NB Capabilities

[Igor Stasenko]

On 8 November 2012 22:50, Jimmie Houchin  wrote:
> I am developing an application which needs to access a proprietary business
> API to access data from their servers.
>
> Currently because I don't know how to do that from within Pharo, I have been
> using Python/COM. But that API is deprecated and expires soon. Now I have to
> move to an app which accesses via either a C/C++ app which accesses a DLL, a
> .NET library or a Java jar.
>
> There are a number of objects that have to be created from the dll/jar, and
> a number of interfaces which have to be implemented from the dll/jar.
> Presently I am studying Clojure in order to work from the Java side. I do
> not know Clojure or Java. If I could learn sufficient C and do this with NB
> in Pharo, that would be very nice.
>
> I have never done anything like what NB does, so I do not know what all it
> does or can do.

It can do anything you can do :)

>
> Can Pharo implement the interfaces provided in the DLL in the Smalltalk
> side?

Pharo can't , you can :)

But if you talk about COM interfaces, then yes. It is doable. The only
problem is,
that it is not done by anyone.

> Or would the interfaces have to be implemented on the C side and then Pharo
> access the objects?
>

AFAIK, COM is fairly simple. You need to do a lill parsing deciphering
IDL interface,
and frankly i don't remember all the details. But at the end, it is
just a bunch of C calls.
With NativeBoost you can do calls to C .. so it is doable.

Again, Dolphin Smalltalk can use COM , so if it can be done there, i
don't see why it is impossible
to do the same in Pharo.

> Any advise greatly appreciated.
>
> Thanks.
>
> Jimmie
>



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-project] NB Capabilities

[Jimmie Houchin]

On 11/8/2012 7:50 PM, Jimmie Houchin wrote:
I am developing an application which needs to access a proprietary 
business API to access data from their servers.


Currently because I don't know how to do that from within Pharo, I 
have been using Python/COM. But that API is deprecated and expires 
soon. Now I have to move to an app which accesses via either a C/C++ 
app which accesses a DLL, a .NET library or a Java jar.


There are a number of objects that have to be created from the 
dll/jar, and a number of interfaces which have to be implemented from 
the dll/jar. Presently I am studying Clojure in order to work from the 
Java side. I do not know Clojure or Java. If I could learn sufficient 
C and do this with NB in Pharo, that would be very nice.


I have never done anything like what NB does, so I do not know what 
all it does or can do.


Can Pharo implement the interfaces provided in the DLL in the 
Smalltalk side?
Or would the interfaces have to be implemented on the C side and then 
Pharo access the objects?


Any advise greatly appreciated.

Thanks.

Jimmie
On a second look at the API's documentation, the DLL is C++ not C. I 
don't know, but that might have been evident by the requirement of 
implementing interfaces.


I thought I would provide that information, just in case in has a big 
bearing NB/Pharo's ability and on my learning curve.


Jimmie

[Pharo-project] NB Capabilities

[Jimmie Houchin]

I am developing an application which needs to access a proprietary 
business API to access data from their servers.


Currently because I don't know how to do that from within Pharo, I have 
been using Python/COM. But that API is deprecated and expires soon. Now 
I have to move to an app which accesses via either a C/C++ app which 
accesses a DLL, a .NET library or a Java jar.


There are a number of objects that have to be created from the dll/jar, 
and a number of interfaces which have to be implemented from the 
dll/jar. Presently I am studying Clojure in order to work from the Java 
side. I do not know Clojure or Java. If I could learn sufficient C and 
do this with NB in Pharo, that would be very nice.


I have never done anything like what NB does, so I do not know what all 
it does or can do.


Can Pharo implement the interfaces provided in the DLL in the Smalltalk 
side?
Or would the interfaces have to be implemented on the C side and then 
Pharo access the objects?


Any advise greatly appreciated.

Thanks.

Jimmie

Re: [Pharo-project] Don't ever ever halt in #startUp:

[Sebastian Sastre]

I'm currently trying Sven idea:

1. use a fresh pharo image (same base version your screwed one's changes is)
2. rename (a copy of) the changes file as .cs
3. open file browser and try to file in that .cs

The first try didn't work because some compilation error.

I've removed the offending code editing manually and trying again

It's slow because is a lot of code

lets see how it ends.

sebastian

o/

PS: about this I won't blame smalltalk at all. This is piece of cake for 
TimeMachine. Problem is that "coincidentally" I've neglected mcz commits for 
the code of this image. The blame is all mine



On Nov 8, 2012, at 7:30 PM, Sebastian Nozzi wrote:

> Hey there Sebastian,
> 
> I feel your pain. Unfortunately there seem to be *many* places / situations 
> where "halting" is a very bad idea and renders your image unusable.
> 
> That's why I think it would be a good idea to have a "list" of these places 
> (in the documentation and in the Pharo "welcome" Workspace), and maybe the 
> technical reasons behind them.
> 
> Something that I did a couple (!!) of times until I learnt the lesson was to 
> halt withing a Morph>>drawnOn:. If you do, then there goes your UI 
> painting/event processing thread (solution: debug your Morph from outside, 
> passing a NullCanvas).
> 
> It was also possible for me, more than once, to "hang" the image beyond 
> recovery (CMD-dot did not help) if "Delaying" ((Delay forMilliseconds: 200) 
> wait) within the UI thread in an infinite recursion (by mistake).
> 
> As for "rescuing it"... can the "recent changes" help you? In your case you 
> would be directly reading the ".changes" file... Not really rescuing your 
> image, but extracting and saving your work... (and migrating to a new image).
> 
> This is very annoying, I know. Been there a couple of times (although with 
> less serious work than yours). In my opinion something needs to change in 
> this area. These are huge productivity losses, and I fear that many new users 
> (*) would at this point turn their backs on Smalltalk never to look back 
> again.
> 
> Best regards,
> 
> Sebastian N.
> 
> (*) or senior developers evaluating the possibility to use Pharo in their 
> companies.
> 
> 
> 2012/11/8 Sebastian Sastre 
> …I mean ever.
> 
> Because you'll screw your image.
> 
> Mostly when you also are on OS X but, for some crazy reason of the Universe, 
> your TimeMachine was not operating normally on your laptop while coding. 
> 
> And you weren't committing in the monticello repo because it was work in 
> progress and you were expecting to reach some goal.
> 
> Ever.
> 
> So…
> 
> I'm in that situation with an image now :(
> 
> I've the false good idea of putting a halt in an SomeApp class>>startUp: 
> method and now, when I open the image, it tries to, stays for about 2 seconds 
> and crashes.
> 
> Any of you guys have a workaround/hack to rescue it?
> 
> sebastian
> 
> o/
> 
> PS: I've tried with startup.st with the code that removes that method but no 
> luck.
> 
> 
> 
> 

Re: [Pharo-project] PluggableListMorph error, how to debug ?

[Sebastian Nozzi]

Hi Laurent,

let me share my way of solving this. My method works from a Workspace or
Inspector/Explorer. What I do is invoke "drawOn:" manually, passing a
NullCanvas (a "dummy" canvas).

Suppose I have a reference (in a Workspace/Inspector) for my buggy morph,
called "m":

m drawOn: (NullCanvas new).

This should trigger the debugger and show you the error. You can then
debug, explore, fix, change, etc. Repeat as needed. Even if the bug is
fixed, the Morph stays in this "erroneous" state. That's why when the bug
is fixed you should call "resumeAfterDrawError" on your Morph:

m resumeAfterDrawError.

And it will re-draw it again.

Hope it helps,

Sebastian



2012/11/4 laurent laffont 

> Hi,
>
> sometimes I have a PluggableListMorph that displays a big red square (see
> attached screenshot). How can I debug why this happens ?
>
> [image: Inline image 1]
>
> Cheers,
>
> Laurent
>
<>

Re: [Pharo-project] Don't ever ever halt in #startUp:

[Sebastian Nozzi]

Cool :-) This will be a default behaviour, or activated through a
command-line switch?

2012/11/8 Camillo Bruni 

> https://code.google.com/p/pharo/issues/detail?id=6941
>
> so that your experience will be last one :)

Re: [Pharo-project] Don't ever ever halt in #startUp:

[blake]

Could you debug the VM and alter the bytecodes?


On Thu, Nov 8, 2012 at 10:51 AM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

> …I mean ever.
>
> Because you'll screw your image.
>
> Mostly when you also are on OS X but, for some crazy reason of the
> Universe, your TimeMachine was not operating normally on your laptop while
> coding.
>
> And you weren't committing in the monticello repo because it was work
> in progress and you were expecting to reach some goal.
>
> Ever.
>
> So…
>
> I'm in that situation with an image now :(
>
> I've the false good idea of putting a halt in an SomeApp class>>startUp:
> method and now, when I open the image, it tries to, stays for about 2
> seconds and crashes.
>
> Any of you guys have a workaround/hack to rescue it?
>
> sebastian 
>
> o/
>
> PS: I've tried with startup.st with the code that removes that method but
> no luck.
>
>
>
>

Re: [Pharo-project] Don't ever ever halt in #startUp:

[Camillo Bruni]

https://code.google.com/p/pharo/issues/detail?id=6941

so that your experience will be last one :)

On 2012-11-08, at 22:49, Camillo Bruni  wrote:

> humm I actually already improved the startup quiet a bit to prevent
> stupid people like me to crash images ;)
> 
> but the halt is not yet caught, I have to add that, then you'll simply
> get a warning at startup :P
> 
> On 2012-11-08, at 22:34, Mariano Martinez Peck  wrote:
> 
>> You can build a VM and skip to the next bytecode ;)
>> http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.html
>> 
>> On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi  wrote:
>>> Hey there Sebastian,
>>> 
>>> I feel your pain. Unfortunately there seem to be *many* places / situations
>>> where "halting" is a very bad idea and renders your image unusable.
>>> 
>>> That's why I think it would be a good idea to have a "list" of these places
>>> (in the documentation and in the Pharo "welcome" Workspace), and maybe the
>>> technical reasons behind them.
>>> 
>>> Something that I did a couple (!!) of times until I learnt the lesson was to
>>> halt withing a Morph>>drawnOn:. If you do, then there goes your UI
>>> painting/event processing thread (solution: debug your Morph from outside,
>>> passing a NullCanvas).
>>> 
>>> It was also possible for me, more than once, to "hang" the image beyond
>>> recovery (CMD-dot did not help) if "Delaying" ((Delay forMilliseconds: 200)
>>> wait) within the UI thread in an infinite recursion (by mistake).
>>> 
>>> As for "rescuing it"... can the "recent changes" help you? In your case you
>>> would be directly reading the ".changes" file... Not really rescuing your
>>> image, but extracting and saving your work... (and migrating to a new
>>> image).
>>> 
>>> This is very annoying, I know. Been there a couple of times (although with
>>> less serious work than yours). In my opinion something needs to change in
>>> this area. These are huge productivity losses, and I fear that many new
>>> users (*) would at this point turn their backs on Smalltalk never to look
>>> back again.
>>> 
>>> Best regards,
>>> 
>>> Sebastian N.
>>> 
>>> (*) or senior developers evaluating the possibility to use Pharo in their
>>> companies.
>>> 
>>> 
>>> 
>>> 2012/11/8 Sebastian Sastre 
 
 …I mean ever.
 
 Because you'll screw your image.
 
 Mostly when you also are on OS X but, for some crazy reason of the
 Universe, your TimeMachine was not operating normally on your laptop while
 coding.
 
 And you weren't committing in the monticello repo because it was work
 in progress and you were expecting to reach some goal.
 
 Ever.
 
 So…
 
 I'm in that situation with an image now :(
 
 I've the false good idea of putting a halt in an SomeApp class>>startUp:
 method and now, when I open the image, it tries to, stays for about 2
 seconds and crashes.
 
 Any of you guys have a workaround/hack to rescue it?
 
 sebastian
 
 o/
 
 PS: I've tried with startup.st with the code that removes that method but
 no luck.
 
 
 
>>> 
>> 
>> 
>> 
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com
>> 
> 

Re: [Pharo-project] Don't ever ever halt in #startUp:

[Camillo Bruni]

humm I actually already improved the startup quiet a bit to prevent
stupid people like me to crash images ;)

but the halt is not yet caught, I have to add that, then you'll simply
get a warning at startup :P

On 2012-11-08, at 22:34, Mariano Martinez Peck  wrote:

> You can build a VM and skip to the next bytecode ;)
> http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.html
> 
> On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi  wrote:
>> Hey there Sebastian,
>> 
>> I feel your pain. Unfortunately there seem to be *many* places / situations
>> where "halting" is a very bad idea and renders your image unusable.
>> 
>> That's why I think it would be a good idea to have a "list" of these places
>> (in the documentation and in the Pharo "welcome" Workspace), and maybe the
>> technical reasons behind them.
>> 
>> Something that I did a couple (!!) of times until I learnt the lesson was to
>> halt withing a Morph>>drawnOn:. If you do, then there goes your UI
>> painting/event processing thread (solution: debug your Morph from outside,
>> passing a NullCanvas).
>> 
>> It was also possible for me, more than once, to "hang" the image beyond
>> recovery (CMD-dot did not help) if "Delaying" ((Delay forMilliseconds: 200)
>> wait) within the UI thread in an infinite recursion (by mistake).
>> 
>> As for "rescuing it"... can the "recent changes" help you? In your case you
>> would be directly reading the ".changes" file... Not really rescuing your
>> image, but extracting and saving your work... (and migrating to a new
>> image).
>> 
>> This is very annoying, I know. Been there a couple of times (although with
>> less serious work than yours). In my opinion something needs to change in
>> this area. These are huge productivity losses, and I fear that many new
>> users (*) would at this point turn their backs on Smalltalk never to look
>> back again.
>> 
>> Best regards,
>> 
>> Sebastian N.
>> 
>> (*) or senior developers evaluating the possibility to use Pharo in their
>> companies.
>> 
>> 
>> 
>> 2012/11/8 Sebastian Sastre 
>>> 
>>> …I mean ever.
>>> 
>>> Because you'll screw your image.
>>> 
>>> Mostly when you also are on OS X but, for some crazy reason of the
>>> Universe, your TimeMachine was not operating normally on your laptop while
>>> coding.
>>> 
>>> And you weren't committing in the monticello repo because it was work
>>> in progress and you were expecting to reach some goal.
>>> 
>>> Ever.
>>> 
>>> So…
>>> 
>>> I'm in that situation with an image now :(
>>> 
>>> I've the false good idea of putting a halt in an SomeApp class>>startUp:
>>> method and now, when I open the image, it tries to, stays for about 2
>>> seconds and crashes.
>>> 
>>> Any of you guys have a workaround/hack to rescue it?
>>> 
>>> sebastian
>>> 
>>> o/
>>> 
>>> PS: I've tried with startup.st with the code that removes that method but
>>> no luck.
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com
> 

Re: [Pharo-project] [Pharo-users] Recovering Changes from a broken image

[Mariano Martinez Peck]

On Thu, Nov 8, 2012 at 10:41 PM, Sebastian Nozzi  wrote:
> This "tip" is very welcome, didn't know that you could import changes made
> from another image.

http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/
title "Recovering lost code:"
I paste it here:

*- Recovering lost code: Probably, one of the things Smalltalkers are
always proud of saying is “In Smalltalk you never lose code” hehhehe. So…
your vm crashed and you didn’t save your code? Well, there are different
ways of recovering the code.

1) Tools -> Recover lost changes. There you can select the date from where
to start watching the changes. Once you select a point in time, you can go
item by item seeing what you want to recover. What I usually do is
multi-select all the ones I want to recover and then I click on “file in
selections”. That will install back those lost changes. Notice that this is
thanks to the .changes file so you need it in order to recover changes.
Also notice that even Do-Its are saved.

2) If your image does not even start, are you screwed up? No! You can even
browse the changes and recover your lost data in ANOTHER image. Just open
another image and then drag and drop the .changes of the image you lost the
data. Then repeat the option 1).

3) You can always take your prefer text editor, open the .changes file and
copy paste *


Should definitely be included in the section "recovering
> lost changes" in the Pharo book (in case it isn't there already ;-).
>
> Also very welcome is a new "description of changes". Without knowing its
> details, may I make a suggestion?
>
> When recovering lost changes what we need is to quickly distinguish (i.e.
> "filter-out") operations on classes/methods and everything else. Having to
> look through all the do-its in order to see if they are "Workspace
> experiments" or important is very time-consuming, and there is always the
> possibility to miss some important "do it", and then the whole "import" is
> stopped.
>
> So it would be great if there were different "filters", and if the changes
> were more explicit.
>
> Other than that, when I needed it, I was grateful that this functionality
> existed at all :-)
>
> Cheers,
>
> Sebastian
>
>
> 2012/11/8 Stéphane Ducasse 
>>
>>
>> On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote:
>>
>> > Hi,
>> >
>> > One of the cool things of Smalltalk's images/changes file is that you
>> > can do a World Menu > Tools > Recover lost changes… to get back most
[1] of
>> > your code in case your image/OS/machine suddenly crashed or you forgot
to
>> > save your image or commit your Monticello packages.
>> >
>> > But we all have encountered the situation where the image is broken,
>> > saved in such a state that it no longer starts up properly. In that
case
>> > your code might seem lost forever.
>> >
>> > No, it is not !
>> >
>> > Two days ago I had this problem myself and I remembered something
Marcus
>> > said some time ago: you can access the changes file of one (in casu
your
>> > broken image) from another (working) image to select/recover the
changes you
>> > want. It worked perfectly.
>> >
>> > The easiest procedure it to copy the .changes file from the broken
image
>> > and rename its extension to .cs and then open it from a World Menu >
Tools >
>> > File Browser and open a Changes browser on it.
>>
>> We should add a recover from another image shortcut.
>> >
>> > I found this very useful. This is a really important technique to be
>> > aware of.
>> >
>> > Sven
>> >
>> > [1] Sadly, not everything is logged in the changes file: creation of
new
>> > classes, method deletions are not recorded.
>>
>> Yes we should change that.
>> Ezequiel started to work on a new description of changes.
>>
>> >
>> > --
>> > Sven Van Caekenberghe
>> > http://stfx.eu
>> > Smalltalk is the Red Pill
>> >
>> >
>> >
>> >
>>
>>
>



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

Re: [Pharo-project] [Pharo-users] Recovering Changes from a broken image

[Sebastian Nozzi]

This "tip" is very welcome, didn't know that you could import changes made
from another image. Should definitely be included in the section
"recovering lost changes" in the Pharo book (in case it isn't there already
;-).

Also very welcome is a new "description of changes". Without knowing its
details, may I make a suggestion?

When recovering lost changes what we need is to quickly distinguish (i.e.
"filter-out") operations on classes/methods and everything else. Having to
look through all the do-its in order to see if they are "Workspace
experiments" or important is very time-consuming, and there is always the
possibility to miss some important "do it", and then the whole "import" is
stopped.

So it would be great if there were different "filters", and if the changes
were more explicit.

Other than that, when I needed it, I was grateful that this functionality
existed at all :-)

Cheers,

Sebastian


2012/11/8 Stéphane Ducasse 

>
> On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote:
>
> > Hi,
> >
> > One of the cool things of Smalltalk's images/changes file is that you
> can do a World Menu > Tools > Recover lost changes… to get back most [1] of
> your code in case your image/OS/machine suddenly crashed or you forgot to
> save your image or commit your Monticello packages.
> >
> > But we all have encountered the situation where the image is broken,
> saved in such a state that it no longer starts up properly. In that case
> your code might seem lost forever.
> >
> > No, it is not !
> >
> > Two days ago I had this problem myself and I remembered something Marcus
> said some time ago: you can access the changes file of one (in casu your
> broken image) from another (working) image to select/recover the changes
> you want. It worked perfectly.
> >
> > The easiest procedure it to copy the .changes file from the broken image
> and rename its extension to .cs and then open it from a World Menu > Tools
> > File Browser and open a Changes browser on it.
>
> We should add a recover from another image shortcut.
> >
> > I found this very useful. This is a really important technique to be
> aware of.
> >
> > Sven
> >
> > [1] Sadly, not everything is logged in the changes file: creation of new
> classes, method deletions are not recorded.
>
> Yes we should change that.
> Ezequiel started to work on a new description of changes.
>
> >
> > --
> > Sven Van Caekenberghe
> > http://stfx.eu
> > Smalltalk is the Red Pill
> >
> >
> >
> >
>
>
>

Re: [Pharo-project] Don't ever ever halt in #startUp:

[Mariano Martinez Peck]

You can build a VM and skip to the next bytecode ;)
http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.html

On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi  wrote:
> Hey there Sebastian,
>
> I feel your pain. Unfortunately there seem to be *many* places / situations
> where "halting" is a very bad idea and renders your image unusable.
>
> That's why I think it would be a good idea to have a "list" of these places
> (in the documentation and in the Pharo "welcome" Workspace), and maybe the
> technical reasons behind them.
>
> Something that I did a couple (!!) of times until I learnt the lesson was to
> halt withing a Morph>>drawnOn:. If you do, then there goes your UI
> painting/event processing thread (solution: debug your Morph from outside,
> passing a NullCanvas).
>
> It was also possible for me, more than once, to "hang" the image beyond
> recovery (CMD-dot did not help) if "Delaying" ((Delay forMilliseconds: 200)
> wait) within the UI thread in an infinite recursion (by mistake).
>
> As for "rescuing it"... can the "recent changes" help you? In your case you
> would be directly reading the ".changes" file... Not really rescuing your
> image, but extracting and saving your work... (and migrating to a new
> image).
>
> This is very annoying, I know. Been there a couple of times (although with
> less serious work than yours). In my opinion something needs to change in
> this area. These are huge productivity losses, and I fear that many new
> users (*) would at this point turn their backs on Smalltalk never to look
> back again.
>
> Best regards,
>
> Sebastian N.
>
> (*) or senior developers evaluating the possibility to use Pharo in their
> companies.
>
>
>
> 2012/11/8 Sebastian Sastre 
>>
>> …I mean ever.
>>
>> Because you'll screw your image.
>>
>> Mostly when you also are on OS X but, for some crazy reason of the
>> Universe, your TimeMachine was not operating normally on your laptop while
>> coding.
>>
>> And you weren't committing in the monticello repo because it was work
>> in progress and you were expecting to reach some goal.
>>
>> Ever.
>>
>> So…
>>
>> I'm in that situation with an image now :(
>>
>> I've the false good idea of putting a halt in an SomeApp class>>startUp:
>> method and now, when I open the image, it tries to, stays for about 2
>> seconds and crashes.
>>
>> Any of you guys have a workaround/hack to rescue it?
>>
>> sebastian
>>
>> o/
>>
>> PS: I've tried with startup.st with the code that removes that method but
>> no luck.
>>
>>
>>
>



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

Re: [Pharo-project] Don't ever ever halt in #startUp:

[Sebastian Nozzi]

Hey there Sebastian,

I feel your pain. Unfortunately there seem to be *many* places / situations
where "halting" is a very bad idea and renders your image unusable.

That's why I think it would be a good idea to have a "list" of these places
(in the documentation and in the Pharo "welcome" Workspace), and maybe the
technical reasons behind them.

Something that I did a couple (!!) of times until I learnt the lesson was
to halt withing a Morph>>drawnOn:. If you do, then there goes your UI
painting/event processing thread (solution: debug your Morph from outside,
passing a NullCanvas).

It was also possible for me, more than once, to "hang" the image beyond
recovery (CMD-dot did not help) if "Delaying" ((Delay forMilliseconds: 200)
wait) within the UI thread in an infinite recursion (by mistake).

As for "rescuing it"... can the "recent changes" help you? In your case you
would be directly reading the ".changes" file... Not really rescuing your
image, but extracting and saving your work... (and migrating to a new
image).

This is very annoying, I know. Been there a couple of times (although with
less serious work than yours). In my opinion something needs to change in
this area. These are huge productivity losses, and I fear that many new
users (*) would at this point turn their backs on Smalltalk never to look
back again.

Best regards,

Sebastian N.

(*) or senior developers evaluating the possibility to use Pharo in their
companies.


2012/11/8 Sebastian Sastre 

> …I mean ever.
>
> Because you'll screw your image.
>
> Mostly when you also are on OS X but, for some crazy reason of the
> Universe, your TimeMachine was not operating normally on your laptop while
> coding.
>
> And you weren't committing in the monticello repo because it was work
> in progress and you were expecting to reach some goal.
>
> Ever.
>
> So…
>
> I'm in that situation with an image now :(
>
> I've the false good idea of putting a halt in an SomeApp class>>startUp:
> method and now, when I open the image, it tries to, stays for about 2
> seconds and crashes.
>
> Any of you guys have a workaround/hack to rescue it?
>
>  sebastian 
>
> o/
>
> PS: I've tried with startup.st with the code that removes that method but
> no luck.
>
>
>
>

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

[Stéphane Ducasse]

On Nov 8, 2012, at 9:13 PM, Sven Van Caekenberghe wrote:

> 
> On 08 Nov 2012, at 20:29, Stéphane Ducasse  wrote:
> 
>> I told you several time, do you think that a guy do not understand what is a 
>> pointer because he does not know how to write it
>> in C?
>> Give a chance to professionals to learn. We are not talking about explaining 
>> what is a pointer, but explaining the 
>> potential problems and challenges
>> 
>> With your reasoning, I should stop programming because there are so many 
>> things that I did not learn in school
>> and I would not have no chance to learn from this community. So with that 
>> reasoning I should better stop working in Smalltalk 
>> and look for another language!
> 
> I think he meant it as a general warning ;-)

yes I know 
> 
> The things is, as long as its pure Smalltalk, you are protected by a very 
> good dynamic type system that cannot really be broken, i.e. the object 
> illusion is kept (bounds checking, blah blah …)

indeed but this means that with a little care we should be able to explain 
points. 
I do not see them as difficult, just full of little details. 

> But once you start using C pointers, you can very easily do something wrong. 
> It might be a very subtle error and it might not manifest itself immediately, 
> alas there won't be a Debugger popping up, just a coredump.
> 
> Pharo is actually pretty/very stable in day to day use, it should stay that 
> way.

oh! yes!

Stef
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
> 
> 
> 
> 

Re: [Pharo-project] [Pharo-users] Recovering Changes from a broken image

[Sven Van Caekenberghe]

On 08 Nov 2012, at 21:09, Stéphane Ducasse  wrote:

> 
> On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote:
> 
>> Hi,
>> 
>> One of the cool things of Smalltalk's images/changes file is that you can do 
>> a World Menu > Tools > Recover lost changes… to get back most [1] of your 
>> code in case your image/OS/machine suddenly crashed or you forgot to save 
>> your image or commit your Monticello packages.
>> 
>> But we all have encountered the situation where the image is broken, saved 
>> in such a state that it no longer starts up properly. In that case your code 
>> might seem lost forever.
>> 
>> No, it is not !
>> 
>> Two days ago I had this problem myself and I remembered something Marcus 
>> said some time ago: you can access the changes file of one (in casu your 
>> broken image) from another (working) image to select/recover the changes you 
>> want. It worked perfectly.
>> 
>> The easiest procedure it to copy the .changes file from the broken image and 
>> rename its extension to .cs and then open it from a World Menu > Tools > 
>> File Browser and open a Changes browser on it.
> 
> We should add a recover from another image shortcut.

Yes! Good idea.

>> I found this very useful. This is a really important technique to be aware 
>> of.
>> 
>> Sven
>> 
>> [1] Sadly, not everything is logged in the changes file: creation of new 
>> classes, method deletions are not recorded.
> 
> Yes we should change that.
> Ezequiel started to work on a new description of changes. 

OK.

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

[Sven Van Caekenberghe]

On 08 Nov 2012, at 20:29, Stéphane Ducasse  wrote:

> I told you several time, do you think that a guy do not understand what is a 
> pointer because he does not know how to write it
> in C?
> Give a chance to professionals to learn. We are not talking about explaining 
> what is a pointer, but explaining the 
> potential problems and challenges
> 
> With your reasoning, I should stop programming because there are so many 
> things that I did not learn in school
> and I would not have no chance to learn from this community. So with that 
> reasoning I should better stop working in Smalltalk 
> and look for another language!

I think he meant it as a general warning ;-)

The things is, as long as its pure Smalltalk, you are protected by a very good 
dynamic type system that cannot really be broken, i.e. the object illusion is 
kept (bounds checking, blah blah …)

But once you start using C pointers, you can very easily do something wrong. It 
might be a very subtle error and it might not manifest itself immediately, alas 
there won't be a Debugger popping up, just a coredump.

Pharo is actually pretty/very stable in day to day use, it should stay that way.

Sven

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill

Re: [Pharo-project] [Pharo-users] Recovering Changes from a broken image

[Stéphane Ducasse]

On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote:

> Hi,
> 
> One of the cool things of Smalltalk's images/changes file is that you can do 
> a World Menu > Tools > Recover lost changes… to get back most [1] of your 
> code in case your image/OS/machine suddenly crashed or you forgot to save 
> your image or commit your Monticello packages.
> 
> But we all have encountered the situation where the image is broken, saved in 
> such a state that it no longer starts up properly. In that case your code 
> might seem lost forever.
> 
> No, it is not !
> 
> Two days ago I had this problem myself and I remembered something Marcus said 
> some time ago: you can access the changes file of one (in casu your broken 
> image) from another (working) image to select/recover the changes you want. 
> It worked perfectly.
> 
> The easiest procedure it to copy the .changes file from the broken image and 
> rename its extension to .cs and then open it from a World Menu > Tools > File 
> Browser and open a Changes browser on it.

We should add a recover from another image shortcut.
> 
> I found this very useful. This is a really important technique to be aware of.
> 
> Sven
> 
> [1] Sadly, not everything is logged in the changes file: creation of new 
> classes, method deletions are not recorded.

Yes we should change that.
Ezequiel started to work on a new description of changes. 

> 
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
> 
> 
> 
> 

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

[Stéphane Ducasse]

 jimmie

***THANKS***
I'm in the same situation even if I read several lectures and books on C.
So I want a tutorials that takes us into account and I'm sure that this is 
faisable.
Just need care, love and time. 

STef

On Nov 8, 2012, at 8:58 PM, Jimmie Houchin wrote:

> On 11/8/2012 1:30 PM, Stéphane Ducasse wrote:
>>> And you can be pretty sure that most pharoers (including myself) have
>>> a pretty vague notion about malloc/free, combined with the internals
>>> of an third party C library, that makes a pretty unstable field.
>>> 
>>> Again, no silver bullets here, but less arrogance and more examples!
>> +1
>> but we can learn and learn fast with a good tutorial that puts the right 
>> amount
>> of information in perspective.
>> 
>> Stef
> I am aperson who has no background in C or similar languages, but would like 
> to learn how to use NB to be able to access methods in DLLs.
> 
> My question is, without becoming a C programmer, what is a sufficient level 
> of knowledge of C to be able to use NB well?
> 
> What is a  good path to acquiring a sufficient level of knowledge?
> 
> Thanks for any information.
> 
> Jimmie
> 

[Pharo-project] Recovering Changes from a broken image

[Sven Van Caekenberghe]

Hi,

One of the cool things of Smalltalk's images/changes file is that you can do a 
World Menu > Tools > Recover lost changes… to get back most [1] of your code in 
case your image/OS/machine suddenly crashed or you forgot to save your image or 
commit your Monticello packages.

But we all have encountered the situation where the image is broken, saved in 
such a state that it no longer starts up properly. In that case your code might 
seem lost forever.

No, it is not !

Two days ago I had this problem myself and I remembered something Marcus said 
some time ago: you can access the changes file of one (in casu your broken 
image) from another (working) image to select/recover the changes you want. It 
worked perfectly.

The easiest procedure it to copy the .changes file from the broken image and 
rename its extension to .cs and then open it from a World Menu > Tools > File 
Browser and open a Changes browser on it.

I found this very useful. This is a really important technique to be aware of.

Sven

[1] Sadly, not everything is logged in the changes file: creation of new 
classes, method deletions are not recorded.

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

[Jimmie Houchin]

On 11/8/2012 1:30 PM, Stéphane Ducasse wrote:

And you can be pretty sure that most pharoers (including myself) have
a pretty vague notion about malloc/free, combined with the internals
of an third party C library, that makes a pretty unstable field.

Again, no silver bullets here, but less arrogance and more examples!

+1
but we can learn and learn fast with a good tutorial that puts the right amount
of information in perspective.

Stef
I am aperson who has no background in C or similar languages, but would 
like to learn how to use NB to be able to access methods in DLLs.


My question is, without becoming a C programmer, what is a sufficient 
level of knowledge of C to be able to use NB well?


What is a  good path to acquiring a sufficient level of knowledge?

Thanks for any information.

Jimmie

Re: [Pharo-project] What did you guys do to startup-time ?

[Stéphane Ducasse]

Thanks Miloslav

This is strange because we are not really satisfied from this point of view. 
There are a lot of cleaning to do to get a snappy morphic.

Stef

> Who snuffed the poor guy ? I don’t know what magic (yea, i know, not just one 
> magic, bunch of magix really ;-) you did but ... I downloaded Pharo 2.0 to 
> give it a whirl (I love smalltalk and keep playing with it / write an app in 
> it every once in a while), unzipped it, doble clicked the binary and the 
> window jumped me so fast i nearly fell of my chair (a positive WTF moment ;-).
>  
> And not just old Mr. Startup Time, you killed Lady Delay too. I remember 
> squeak / older pharo versions feeling a bit sluggish (a slight delay between 
> clicking and the menu popping up / whatever), but now it is blazing fast.
>  
> Just saying „Great work“ would be an understatement / denigration.
>  
> * rausm deeply bows in silent awe

Re: [Pharo-project] New command line option: load updates

[Stéphane Ducasse]

Cool!
I like the noise of the falling of large bash scripts.
The lesser the better 

Stef

> Hi,
> 
> There is now a command line option to load updates.
> 
> To test it:
> 
> wget --quiet -qO - http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | bash
> 
> ./vm.sh Pharo.image update
> 
> What is does it to load updates, then snapshot and quit.
> 
> The idea is to use this in the new CI setup so we don't need any external 
> scripts.
> 
> --
> Marcus Denker -- http://marcusdenker.de
> 
> 

Re: [Pharo-project] [update 2.0] #20386

[Pavel Krivanek]

:-) you were faster.. with the same code ;-)

-- Pavel

On Thu, Nov 8, 2012 at 8:29 PM, Esteban Lorenzano  wrote:
> oops! fix in inbox :)
>
> On Nov 8, 2012, at 8:13 PM, Pavel Krivanek  wrote:
>
>> On Thu, Nov 8, 2012 at 5:59 PM, Marcus Denker  wrote:
>>> [update 2.0] #20386
>>> 20386
>>> -
>>>
>>> Issue 6933: Fixing the fact that typing ...
>>>http://code.google.com/p/pharo/issues/detail?id=6933
>>>
>>> Issue 6853: Monticello merge conflicts on reordered package names
>>>http://code.google.com/p/pharo/issues/detail?id=6853
>>>
>>> Issue 6760: Traits dont get repackaged
>>>http://code.google.com/p/pharo/issues/detail?id=6760
>>>
>>
>> it seems that something is wrong with this Traits fix, when I try to
>> load tests to the Pharo Kernel, I started to got this error:
>>
>> 10 UndefinedObject(Object)>>doesNotUnderstand: #category
>> 11 Trait class>>named:uses:category:env:
>> 12 Trait class>>named:uses:category:
>> 13 UndefinedObject>>DoIt
>>
>> The full stack:
>>
>> Error:
>> MessageNotUnderstood: receiver of "category" is nil
>> 68
>> 1 [:t2 |
>> | t3 |
>> t3 := FileStream forceNewFileNamed: 'PharoDebug.log'.
>>   t3 nextPutAll: 'Error:';
>>cr.
>>   t3 nextPutAll: t2 asString;
>>cr.
>>   t3 nextPutAll: thisContext stack size asString;
>>cr.
>>   thisContext stack copy
>>   withIndexDo: [:t4 :t5 | [t3 nextPutAll: t5 asString;
>>space;
>>nextPutAll: t4 asString;
>>cr]
>>   ifError: [:t6 | t3 nextPutAll: t6 asString;
>>cr]].
>>   t3 close.
>>   Smalltalk exitFailure] in UndefinedObject>>DoIt
>> 2 BlockClosure>>cull:
>> 3 BlockClosure>>cull:cull:
>> 4 [:ex | errorHandlerBlock cull: ex description cull: ex receiver] in
>> BlockClosure>>ifError:
>> 5 BlockClosure>>cull:
>> 6 [self exceptionHandlerBlock cull: exception] in
>> MethodContext(ContextPart)>>handleSignal:
>> 7 BlockClosure>>ensure:
>> 8 MethodContext(ContextPart)>>handleSignal:
>> 9 MessageNotUnderstood(Exception)>>signal
>> 10 UndefinedObject(Object)>>doesNotUnderstand: #category
>> 11 Trait class>>named:uses:category:env:
>> 12 Trait class>>named:uses:category:
>> 13 UndefinedObject>>DoIt
>> 14 Compiler>>evaluate:in:to:notifying:ifFail:logged:
>> 15 Compiler class>>evaluate:for:notifying:logged:
>> 16 Compiler class>>evaluate:for:logged:
>> 17 Compiler class>>evaluate:logged:
>> 18 DoItDeclaration>>import
>> 19 [:decl | value := decl import] in CodeImporter>>evaluateDeclarations
>> 20 OrderedCollection>>do:
>> 21 CodeImporter>>evaluateDeclarations
>> 22 CodeImporter class>>evaluateReadStream:
>> 23 [:t2 |
>> CodeImporter evaluateReadStream: (t2 , '.st') asFileReference readStream.
>>   FileStream stdout nextPutAll: t2 , ' loaded';
>>lf] in ['SUnit-Core
>> SUnit-Tests
>> CollectionsTests
>> Announcements-Tests-Core
>> CompilerTests
>> CompressionTests
>> FileSystem-Tests-AnsiStreams
>> FileSystem-Tests-Core
>> FileSystem-Tests-Disk
>> FileSystem-Tests-Memory
>> KernelTests
>> Multilingual-Tests
>> Ring-Tests-Kernel
>> Ring-Tests-Containers
>> Tests-Bugs
>> Tests-CodeImport
>> Tests-Compression
>> Tests-Exceptions
>> Tests-Files
>> Tests-Finalization
>> Tests-Localization
>> Tests-Object Events
>> Tests-ObjectsAsMethods
>> Tests-Release
>> FooSharedPool
>> Tests-System
>> Tests-System-CommandLine
>> Tests-SystemChangeNotification
>> Tests-SystemTests-Support
>> Tests-Traits
>> Tests-Traits-MOP
>> Tests-VM
>> HudsonBuildTools'
>>   linesDo: [:t2 |
>>   CodeImporter evaluateReadStream: (t2 , '.st') 
>> asFileReference readStream.
>>   FileStream stdout nextPutAll: t2 , ' loaded';
>>lf].
>>   FileStream stdout nextPutAll: 'Load tests finished';
>>lf.
>>   SmalltalkImage current snapshot: true andQuit: true] in 
>> UndefinedObject>>DoIt
>> 24 [:start :endWithoutDelimiters :end | aBlock
>>   value: (self copyFrom: start to: endWithoutDelimiters)] in
>> ByteString(String)>>linesDo:
>> 25 ByteString(String)>>lineIndicesDo:
>> 26 ByteString(String)>>linesDo:
>> 27 ['SUnit-Core
>> SUnit-Tests
>> CollectionsTests
>> Announcements-Tests-Core
>> CompilerTests
>> CompressionTests
>> FileSystem-Tests-AnsiStreams
>> FileSystem-Tests-Core
>> FileSystem-Tests-Disk
>> FileSystem-Tests-Memory
>> KernelTests
>> Multilingual-Tests
>> Ring-Tests-Kernel
>> Ring-Tests-Containers
>> Tests-Bugs
>> Tests-CodeImport
>> Tests-Compression
>> Tests-Exceptions
>> Tests-Files
>> Tests-Finalization
>> Tests-Localization
>> Tests-Object Events
>> Tests-ObjectsAsMethods
>> Tests-Release
>> FooSharedPool
>> Tests-System
>> Tests-System-CommandLine
>> Tests-SystemChangeNotification
>> Tests-SystemTests-Support
>> Tests-Traits
>> Tests-Traits-MOP
>> Tests-VM
>> H

Re: [Pharo-project] [Pharo-consortium] [Pharo-users] Pharo consortium agreement

[Stéphane Ducasse]

On Nov 8, 2012, at 4:03 AM, Igor Stasenko wrote:

> On 6 November 2012 15:36, Sven Van Caekenberghe  wrote:
>> Very good that there is progress on this front !
>> 
>> Even better news about Igor ;-)
>> 
> i always asking myself, if this horse worth its bets.
> Thank you, Stephane & others for putting trust in me more than i do :)

As a thank, write a tutorial and doc on FFI and NativeBoost 
with a lot of documented examples ;D

> 
>> Indeed: thank you INRIA for sponsoring Pharo.
>> 
>> I will read the document this evening.
>> 
>> --
>> Sven Van Caekenberghe
>> http://stfx.eu
>> Smalltalk is the Red Pill
>> 
>> 
>> 
>> On 06 Nov 2012, at 17:24, Stéphane Ducasse  wrote:
>> 
>>> Dear Pharoers
>>> 
>>> Here is the result of the work we did around the consortium for Pharo for 
>>> about 2 years. We took into account all your remarks over the years
>>> and we think that the result is good and corresponds to what the community 
>>> can support.
>>> This consortium is important for Pharo's future and it will help us to 
>>> deliver a system to help you making business.
>>> Our goal is to be able to collect fundings to pay at least one full time 
>>> engineer.
>>> 
>>> The idea is that all the consortium members will sign the same agreement. 
>>> We will not handle modifications per partners.
>>> Now since we are starting the process if you spot some glitches on the form 
>>> let us know. We can discuss and fully stabilize one version.
>>> 
>>> We suggest to read the document.
>>>  - If you agree to sign it and send it to us (in two copies if you do 
>>> it by surface mail at
>>>  INRIA - S. Ducasse - Pharo, 40, avenue Halley, Parc 
>>> Scientifique de la Haute Borne,
>>>  Bât.A, Park Plaza, Villeneuve d'Ascq,  FR-59650, 
>>> France.), so that we sign it too.
>>>  - Don't forget to complete your legal mention on first page and your 
>>> contact details on article 14 before signing. :)
>>> 
>>> We will launch soon two web sites:
>>>  - one for the Pharo user association and
>>>  - one for the Pharo consortium.
>>> 
>>> 
>>> A side note: we will communicate about it later and separately but Inria 
>>> decided to support the consortium by paying one extra year to Igor Stasenko.
>>> This is around 60 Keuros in addition to the year of Esteban Lorenzano and 
>>> previous years of Igor.
>>> 
>>> I really want to thank Inria for the constant support and the work of S. 
>>> Karpf, P. Moreau and S. Perin.
>>> 
>>> Stef
>>> 
>>> <2012-11-06-consortium PHARO.pdf>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Dr. Stéphane Ducasse -- Directeur de Recherche (Senior Researcher)
>>> INRIA - USTL - CNRS UMR 8022
>>> stephane.duca...@inria.fr
>>> http://stephane.ducasse.free.fr
>>> http://rmod.lille.inria.fr/
>>> **NEW ***Tel 00 33 (0)3 59 35 87 52  - Fax 33 3 59 57 78 50
>>> 
>>> 40, avenue Halley, Parc Scientifique de la Haute Borne,
>>> Bât.A, Park Plaza, Villeneuve d'Ascq,  FR-59650, France.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 
> ___
> Pharo-consortium mailing list
> pharo-consort...@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-consortium

Re: [Pharo-project] PluggableListMorph error, how to debug ?

[Stéphane Ducasse]

>> 
>> 
> Debugging UI code is one of those places you probably want to insert a 
> haltOnce instead, or risk losing the image :)

and event :) and shortcut code :)

Re: [Pharo-project] [Jenkins] about Pharo ci infrastructure...

[Stéphane Ducasse]

On Nov 8, 2012, at 1:43 AM, Igor Stasenko wrote:

> This is really good news!
> I really like that INRIA pays attention to issues we having and takes
> into account our experience and input.
> This is, of course, what anyone would expect from any reasonable organization 
> :)

but to me I do not know that many public funded organization that offer such 
level.

For example we never got any engineers before coming at INRIA :).

Stef

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

[Stéphane Ducasse]

> And you can be pretty sure that most pharoers (including myself) have
> a pretty vague notion about malloc/free, combined with the internals
> of an third party C library, that makes a pretty unstable field.
> 
> Again, no silver bullets here, but less arrogance and more examples!

+1 
but we can learn and learn fast with a good tutorial that puts the right amount 
of information in perspective.

Stef

Re: [Pharo-project] [update 2.0] #20386

[Esteban Lorenzano]

oops! fix in inbox :)

On Nov 8, 2012, at 8:13 PM, Pavel Krivanek  wrote:

> On Thu, Nov 8, 2012 at 5:59 PM, Marcus Denker  wrote:
>> [update 2.0] #20386
>> 20386
>> -
>> 
>> Issue 6933: Fixing the fact that typing ...
>>http://code.google.com/p/pharo/issues/detail?id=6933
>> 
>> Issue 6853: Monticello merge conflicts on reordered package names
>>http://code.google.com/p/pharo/issues/detail?id=6853
>> 
>> Issue 6760: Traits dont get repackaged
>>http://code.google.com/p/pharo/issues/detail?id=6760
>> 
> 
> it seems that something is wrong with this Traits fix, when I try to
> load tests to the Pharo Kernel, I started to got this error:
> 
> 10 UndefinedObject(Object)>>doesNotUnderstand: #category
> 11 Trait class>>named:uses:category:env:
> 12 Trait class>>named:uses:category:
> 13 UndefinedObject>>DoIt
> 
> The full stack:
> 
> Error:
> MessageNotUnderstood: receiver of "category" is nil
> 68
> 1 [:t2 |
> | t3 |
> t3 := FileStream forceNewFileNamed: 'PharoDebug.log'.
>   t3 nextPutAll: 'Error:';
>cr.
>   t3 nextPutAll: t2 asString;
>cr.
>   t3 nextPutAll: thisContext stack size asString;
>cr.
>   thisContext stack copy
>   withIndexDo: [:t4 :t5 | [t3 nextPutAll: t5 asString;
>space;
>nextPutAll: t4 asString;
>cr]
>   ifError: [:t6 | t3 nextPutAll: t6 asString;
>cr]].
>   t3 close.
>   Smalltalk exitFailure] in UndefinedObject>>DoIt
> 2 BlockClosure>>cull:
> 3 BlockClosure>>cull:cull:
> 4 [:ex | errorHandlerBlock cull: ex description cull: ex receiver] in
> BlockClosure>>ifError:
> 5 BlockClosure>>cull:
> 6 [self exceptionHandlerBlock cull: exception] in
> MethodContext(ContextPart)>>handleSignal:
> 7 BlockClosure>>ensure:
> 8 MethodContext(ContextPart)>>handleSignal:
> 9 MessageNotUnderstood(Exception)>>signal
> 10 UndefinedObject(Object)>>doesNotUnderstand: #category
> 11 Trait class>>named:uses:category:env:
> 12 Trait class>>named:uses:category:
> 13 UndefinedObject>>DoIt
> 14 Compiler>>evaluate:in:to:notifying:ifFail:logged:
> 15 Compiler class>>evaluate:for:notifying:logged:
> 16 Compiler class>>evaluate:for:logged:
> 17 Compiler class>>evaluate:logged:
> 18 DoItDeclaration>>import
> 19 [:decl | value := decl import] in CodeImporter>>evaluateDeclarations
> 20 OrderedCollection>>do:
> 21 CodeImporter>>evaluateDeclarations
> 22 CodeImporter class>>evaluateReadStream:
> 23 [:t2 |
> CodeImporter evaluateReadStream: (t2 , '.st') asFileReference readStream.
>   FileStream stdout nextPutAll: t2 , ' loaded';
>lf] in ['SUnit-Core
> SUnit-Tests
> CollectionsTests
> Announcements-Tests-Core
> CompilerTests
> CompressionTests
> FileSystem-Tests-AnsiStreams
> FileSystem-Tests-Core
> FileSystem-Tests-Disk
> FileSystem-Tests-Memory
> KernelTests
> Multilingual-Tests
> Ring-Tests-Kernel
> Ring-Tests-Containers
> Tests-Bugs
> Tests-CodeImport
> Tests-Compression
> Tests-Exceptions
> Tests-Files
> Tests-Finalization
> Tests-Localization
> Tests-Object Events
> Tests-ObjectsAsMethods
> Tests-Release
> FooSharedPool
> Tests-System
> Tests-System-CommandLine
> Tests-SystemChangeNotification
> Tests-SystemTests-Support
> Tests-Traits
> Tests-Traits-MOP
> Tests-VM
> HudsonBuildTools'
>   linesDo: [:t2 |
>   CodeImporter evaluateReadStream: (t2 , '.st') 
> asFileReference readStream.
>   FileStream stdout nextPutAll: t2 , ' loaded';
>lf].
>   FileStream stdout nextPutAll: 'Load tests finished';
>lf.
>   SmalltalkImage current snapshot: true andQuit: true] in 
> UndefinedObject>>DoIt
> 24 [:start :endWithoutDelimiters :end | aBlock
>   value: (self copyFrom: start to: endWithoutDelimiters)] in
> ByteString(String)>>linesDo:
> 25 ByteString(String)>>lineIndicesDo:
> 26 ByteString(String)>>linesDo:
> 27 ['SUnit-Core
> SUnit-Tests
> CollectionsTests
> Announcements-Tests-Core
> CompilerTests
> CompressionTests
> FileSystem-Tests-AnsiStreams
> FileSystem-Tests-Core
> FileSystem-Tests-Disk
> FileSystem-Tests-Memory
> KernelTests
> Multilingual-Tests
> Ring-Tests-Kernel
> Ring-Tests-Containers
> Tests-Bugs
> Tests-CodeImport
> Tests-Compression
> Tests-Exceptions
> Tests-Files
> Tests-Finalization
> Tests-Localization
> Tests-Object Events
> Tests-ObjectsAsMethods
> Tests-Release
> FooSharedPool
> Tests-System
> Tests-System-CommandLine
> Tests-SystemChangeNotification
> Tests-SystemTests-Support
> Tests-Traits
> Tests-Traits-MOP
> Tests-VM
> HudsonBuildTools'
>   linesDo: [:t2 |
>   CodeImporter evaluateReadStream: (t2 , '.st') 
> asFileReference readStream.
>   FileStream stdout nextPutAll: t2 , ' loaded';
>lf].
> 

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

[Stéphane Ducasse]

Again 

I told you several time, do you think that a guy do not understand what is a 
pointer because he does not know how to write it
in C?
Give a chance to professionals to learn. We are not talking about explaining 
what is a pointer, but explaining the 
potential problems and challenges

With your reasoning, I should stop programming because there are so many things 
that I did not learn in school
and I would not have no chance to learn from this community. So with that 
reasoning I should better stop working in Smalltalk 
and look for another language!

Stef

> sure sure..
> but guys... i really doubt that i would want to see people poking with
> NB who don't even have a
> basic understanding of malloc(ed) memory management and working with
> memory buffers & pointers.
> For such sort of people, best what i can offer is "go back when you
> will learn basics first".
> 
> Of course, it would be cool if NB could work even for "dummies", but i
> am thinking , as any technology,
> before you start using it without shooting yourself into foot, you
> should do some homework first.
> 
> 
> On 7 November 2012 08:09, Stéphane Ducasse  wrote:
>> + 1
>> 
>> On Nov 7, 2012, at 9:43 AM, Camillo Bruni wrote:
>> 
>>> Just copy paste the thing you posted in the NBBasicExamples and we're
>>> done. A couple of examples which show common problems will help
>>> certainly help people to understand.
>>> 
>>> Plus we should convert the examples into tests so they are always run!
>>> 
>>> On 2012-11-07, at 09:28, Stéphane Ducasse  wrote:
>>> 
 
 On Nov 6, 2012, at 11:06 PM, Igor Stasenko wrote:
 
> On 6 November 2012 17:57, Stéphane Ducasse  
> wrote:
>> This is clearly something to add to the documentation of NativeBoost.
>> Igor can you do it?
> 
> I already have a description of memory management API for NB in docs.
> And telling how manage external memory is... ahem.. not really fits into 
> docs :)
> Maybe a tutor or something.
 
 think not technical but user!
 Id o not give a shit if what helps me is called a doc or a tutorial.
 I care that it helps me fixing my problem.
 And what I see is that the example of Max is a nice example of a recurring 
 problem
 people face.
 
 Stef
> 
> 
> 
> --
> Best regards,
> Igor Stasenko.
> 
 
 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] [update 2.0] #20386

[Pavel Krivanek]

On Thu, Nov 8, 2012 at 5:59 PM, Marcus Denker  wrote:
> [update 2.0] #20386
> 20386
> -
>
> Issue 6933: Fixing the fact that typing ...
> http://code.google.com/p/pharo/issues/detail?id=6933
>
> Issue 6853: Monticello merge conflicts on reordered package names
> http://code.google.com/p/pharo/issues/detail?id=6853
>
> Issue 6760: Traits dont get repackaged
> http://code.google.com/p/pharo/issues/detail?id=6760
>

it seems that something is wrong with this Traits fix, when I try to
load tests to the Pharo Kernel, I started to got this error:

10 UndefinedObject(Object)>>doesNotUnderstand: #category
11 Trait class>>named:uses:category:env:
12 Trait class>>named:uses:category:
13 UndefinedObject>>DoIt

The full stack:

Error:
MessageNotUnderstood: receiver of "category" is nil
68
1 [:t2 |
| t3 |
t3 := FileStream forceNewFileNamed: 'PharoDebug.log'.
t3 nextPutAll: 'Error:';
 cr.
t3 nextPutAll: t2 asString;
 cr.
t3 nextPutAll: thisContext stack size asString;
 cr.
thisContext stack copy
withIndexDo: [:t4 :t5 | [t3 nextPutAll: t5 asString;
 space;
 nextPutAll: t4 asString;
 cr]
ifError: [:t6 | t3 nextPutAll: t6 asString;
 cr]].
t3 close.
Smalltalk exitFailure] in UndefinedObject>>DoIt
2 BlockClosure>>cull:
3 BlockClosure>>cull:cull:
4 [:ex | errorHandlerBlock cull: ex description cull: ex receiver] in
BlockClosure>>ifError:
5 BlockClosure>>cull:
6 [self exceptionHandlerBlock cull: exception] in
MethodContext(ContextPart)>>handleSignal:
7 BlockClosure>>ensure:
8 MethodContext(ContextPart)>>handleSignal:
9 MessageNotUnderstood(Exception)>>signal
10 UndefinedObject(Object)>>doesNotUnderstand: #category
11 Trait class>>named:uses:category:env:
12 Trait class>>named:uses:category:
13 UndefinedObject>>DoIt
14 Compiler>>evaluate:in:to:notifying:ifFail:logged:
15 Compiler class>>evaluate:for:notifying:logged:
16 Compiler class>>evaluate:for:logged:
17 Compiler class>>evaluate:logged:
18 DoItDeclaration>>import
19 [:decl | value := decl import] in CodeImporter>>evaluateDeclarations
20 OrderedCollection>>do:
21 CodeImporter>>evaluateDeclarations
22 CodeImporter class>>evaluateReadStream:
23 [:t2 |
CodeImporter evaluateReadStream: (t2 , '.st') asFileReference readStream.
FileStream stdout nextPutAll: t2 , ' loaded';
 lf] in ['SUnit-Core
SUnit-Tests
CollectionsTests
Announcements-Tests-Core
CompilerTests
CompressionTests
FileSystem-Tests-AnsiStreams
FileSystem-Tests-Core
FileSystem-Tests-Disk
FileSystem-Tests-Memory
KernelTests
Multilingual-Tests
Ring-Tests-Kernel
Ring-Tests-Containers
Tests-Bugs
Tests-CodeImport
Tests-Compression
Tests-Exceptions
Tests-Files
Tests-Finalization
Tests-Localization
Tests-Object Events
Tests-ObjectsAsMethods
Tests-Release
FooSharedPool
Tests-System
Tests-System-CommandLine
Tests-SystemChangeNotification
Tests-SystemTests-Support
Tests-Traits
Tests-Traits-MOP
Tests-VM
HudsonBuildTools'
linesDo: [:t2 |
CodeImporter evaluateReadStream: (t2 , '.st') 
asFileReference readStream.
FileStream stdout nextPutAll: t2 , ' loaded';
 lf].
FileStream stdout nextPutAll: 'Load tests finished';
 lf.
SmalltalkImage current snapshot: true andQuit: true] in 
UndefinedObject>>DoIt
24 [:start :endWithoutDelimiters :end | aBlock
value: (self copyFrom: start to: endWithoutDelimiters)] in
ByteString(String)>>linesDo:
25 ByteString(String)>>lineIndicesDo:
26 ByteString(String)>>linesDo:
27 ['SUnit-Core
SUnit-Tests
CollectionsTests
Announcements-Tests-Core
CompilerTests
CompressionTests
FileSystem-Tests-AnsiStreams
FileSystem-Tests-Core
FileSystem-Tests-Disk
FileSystem-Tests-Memory
KernelTests
Multilingual-Tests
Ring-Tests-Kernel
Ring-Tests-Containers
Tests-Bugs
Tests-CodeImport
Tests-Compression
Tests-Exceptions
Tests-Files
Tests-Finalization
Tests-Localization
Tests-Object Events
Tests-ObjectsAsMethods
Tests-Release
FooSharedPool
Tests-System
Tests-System-CommandLine
Tests-SystemChangeNotification
Tests-SystemTests-Support
Tests-Traits
Tests-Traits-MOP
Tests-VM
HudsonBuildTools'
linesDo: [:t2 |
CodeImporter evaluateReadStream: (t2 , '.st') 
asFileReference readStream.
FileStream stdout nextPutAll: t2 , ' loaded';
 lf].
FileStream stdout nextPutAll: 'Load tests finished';
 lf.
SmalltalkImage current snapshot: true andQuit: true] in 
UndefinedObject>>DoIt
28 BlockClosure>>on:do:
29 BlockClosure>>ifError:
30 UndefinedObject>>DoIt
31 Compiler>>evaluate:in:to:notifying:ifFail:logged:
32 Compiler class>>evaluate:

[Pharo-project] Don't ever ever halt in #startUp:

[Sebastian Sastre]

…I mean ever.

Because you'll screw your image.

Mostly when you also are on OS X but, for some crazy reason of the Universe, 
your TimeMachine was not operating normally on your laptop while coding. 

And you weren't committing in the monticello repo because it was work in 
progress and you were expecting to reach some goal.

Ever.

So…

I'm in that situation with an image now :(

I've the false good idea of putting a halt in an SomeApp class>>startUp: method 
and now, when I open the image, it tries to, stays for about 2 seconds and 
crashes.

Any of you guys have a workaround/hack to rescue it?

sebastian

o/

PS: I've tried with startup.st with the code that removes that method but no 
luck.

[Pharo-project] pharo-2.0-tests » win - Build # 468 - Still Failing!

[jenkins-pharo . ci . inria . fr]

BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/pharo-2.0-tests/./label_exp=win/468/Project:label_exp=winDate of build:Thu, 08 Nov 2012 19:35:36 +0100Build duration:10 minCHANGESNo ChangesBUILD ARTIFACTSPharo-2.0-AfterRunningTests/ClassHierarchyTest-testMethodDuplication.fuelPharo-2.0-AfterRunningTests/ClosureCompilerTest-testDebuggerTempAccess.fuelPharo-2.0-AfterRunningTests/ClosureCompilerTest-testInjectIntoDecompilations.fuelPharo-2.0-AfterRunningTests/ClosureCompilerTest-testInjectIntoDecompiledDebugs.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testCaseOtherwiseBlockWithArgument.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testifTrueBlockWithArgument.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testInvalidLiteralCharacter.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testTooManyArguments.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testTooManyLiterals.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testCaseOtherwiseBlockWithArgument.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testifTrueBlockWithArgument.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testInvalidLiteralCharacter.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testTooManyArguments.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testTooManyLiterals.fuelPharo-2.0-AfterRunningTests/DateAndTimeTest-testNotSymmetricWithString.fuelPharo-2.0-AfterRunningTests/FLBasicSerializationTest-testConsiderCustomWideSymbolGlobal.fuelPharo-2.0-AfterRunningTests/FLCompiledMethodSerializationTest-testMethodWithUndeclaredGlobal.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateClassWithCreatedTrait.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateWithClassTrait.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateWithExternalTrait.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateWithInternalTrait.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateWithTraitOnClassSide.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCompiledMethodClassBinding.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateBasic.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithClassSideMethod.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithClassTrait.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithComment.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithExternalTrait.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithInstance.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithInternalTrait.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithMethod.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithTraitOnClassSide.fuelPharo-2.0-AfterRunningTests/FLFullBasicSerializationTest-testConsiderCustomWideSymbolGlobal.fuelPharo-2.0-AfterRunningTests/FLFullBasicSerializationTest-testUndeclaredAssociation.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testClassSideMethodNotFoundAfterRemoval.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testClassSideMethodPreservesIdentity.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testClassSideObsolete.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testClassSidePreservesIdentity.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testMethodNotFoundAfterRemoval.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testMethodPreservesIdentity.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testNotFoundAfterRemoval.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testNotFoundAfterRename.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testObsolete.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testPreservesIdentity.fuelPharo-2.0-AfterRunningTests/FLInMemoryBasicSerializationTest-testConsiderCustomWideSymbolGlobal.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorAt.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorClass.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorEqEq.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorInstVarAt.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorPerform.fuelPharo-2.0-AfterRunningTests/ObsoleteTest-testTraitObsolete.fuelPharo-2.0-AfterRunningTests/ReleaseTest-testObsoleteClasses.fuelPharo-2.0-AfterRunningTests/ReleaseTest-testUndeclared.fuelPharo-2.0-AfterRunningTests/ReleaseTest-testUnimplementedNonPrimitiveCalls.fuelPharo-2.0-AfterRunningTests/RPackageMethodsSynchronisationTest-testAddMethodInClassicCategoryAddMethodToTheParentPackageOfItsTrait.fuelPharo-2.0-AfterRunningTests/RPackageReadOnlyCompleteSetupTest-testClassesA

Re: [Pharo-project] [Jenkins] about Pharo ci infrastructure...

[Marcus Denker]

On Nov 7, 2012, at 5:02 PM, Marcus Denker  wrote:

> Hello,
> 
> We are experiencing some stability issues with 
> https://ci.lille.inria.fr/pharo/
> 
> But the good news is: people here have been busy, and there will be a 
> completely new
> ci infrastructure soon.
> 

First job for Pharo 2.0:

https://ci.inria.fr/pharo/job/Pharo-2.0/

no one-click yet...


Marcus


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

[Pharo-project] pharo-2.0-tests » win - Build # 467 - Failure!

[jenkins-pharo . ci . inria . fr]

BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/pharo-2.0-tests/./label_exp=win/467/Project:label_exp=winDate of build:Thu, 08 Nov 2012 18:20:13 +0100Build duration:9 min 8 secCHANGESNo ChangesBUILD ARTIFACTSPharo-2.0-AfterRunningTests/ClassHierarchyTest-testMethodDuplication.fuelPharo-2.0-AfterRunningTests/ClosureCompilerTest-testDebuggerTempAccess.fuelPharo-2.0-AfterRunningTests/ClosureCompilerTest-testInjectIntoDecompilations.fuelPharo-2.0-AfterRunningTests/ClosureCompilerTest-testInjectIntoDecompiledDebugs.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testCaseOtherwiseBlockWithArgument.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testifTrueBlockWithArgument.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testInvalidLiteralCharacter.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testTooManyArguments.fuelPharo-2.0-AfterRunningTests/CompilerNotifyingTest-testTooManyLiterals.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testCaseOtherwiseBlockWithArgument.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testifTrueBlockWithArgument.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testInvalidLiteralCharacter.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testTooManyArguments.fuelPharo-2.0-AfterRunningTests/CompilerSyntaxErrorNotifyingTest-testTooManyLiterals.fuelPharo-2.0-AfterRunningTests/DateAndTimeTest-testNotSymmetricWithString.fuelPharo-2.0-AfterRunningTests/FLBasicSerializationTest-testConsiderCustomWideSymbolGlobal.fuelPharo-2.0-AfterRunningTests/FLCompiledMethodSerializationTest-testMethodWithUndeclaredGlobal.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateClassWithCreatedTrait.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateWithClassTrait.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateWithExternalTrait.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateWithInternalTrait.fuelPharo-2.0-AfterRunningTests/FLCreateClassSerializationTest-testCreateWithTraitOnClassSide.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCompiledMethodClassBinding.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateBasic.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithClassSideMethod.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithClassTrait.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithComment.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithExternalTrait.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithInstance.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithInternalTrait.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithMethod.fuelPharo-2.0-AfterRunningTests/FLCreateTraitSerializationTest-testCreateWithTraitOnClassSide.fuelPharo-2.0-AfterRunningTests/FLFullBasicSerializationTest-testConsiderCustomWideSymbolGlobal.fuelPharo-2.0-AfterRunningTests/FLFullBasicSerializationTest-testUndeclaredAssociation.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testClassSideMethodNotFoundAfterRemoval.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testClassSideMethodPreservesIdentity.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testClassSideObsolete.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testClassSidePreservesIdentity.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testMethodNotFoundAfterRemoval.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testMethodPreservesIdentity.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testNotFoundAfterRemoval.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testNotFoundAfterRename.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testObsolete.fuelPharo-2.0-AfterRunningTests/FLGlobalTraitSerializationTest-testPreservesIdentity.fuelPharo-2.0-AfterRunningTests/FLInMemoryBasicSerializationTest-testConsiderCustomWideSymbolGlobal.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorAt.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorClass.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorEqEq.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorInstVarAt.fuelPharo-2.0-AfterRunningTests/MirrorPrimitiveTests-testMirrorPerform.fuelPharo-2.0-AfterRunningTests/ObsoleteTest-testTraitObsolete.fuelPharo-2.0-AfterRunningTests/ReleaseTest-testObsoleteClasses.fuelPharo-2.0-AfterRunningTests/ReleaseTest-testUndeclared.fuelPharo-2.0-AfterRunningTests/ReleaseTest-testUnimplementedNonPrimitiveCalls.fuelPharo-2.0-AfterRunningTests/RPackageMethodsSynchronisationTest-testAddMethodInClassicCategoryAddMethodToTheParentPackageOfItsTrait.fuelPharo-2.0-AfterRunningTests/RPackageReadOnlyCompleteSetupTest-testCla

Re: [Pharo-project] Opening a serial Port with Pharo on Linux

[Luc Fabresse]

2012/11/8 Friedrich Dominicus 

> Luc Fabresse  writes:
>
> > Hi Friedrich,
> >
> >  I did not test myself but I will soon.
> >  Since the Jenkins is down, you can found the latest VM (with the
> SerialPlugin
> > modifications that Esteban did) in my dropbox:
> > https://www.dropbox.com/sh/flx2cc8mjszhckg/uZ8sTxSB1k
> Ok I downloaded this Virtual Machine and tried it, but still the erro
> persists:
> 8 November 2012 5:24:29.474 pm
>
> VM: unix - i686 - linux-gnu - CoInterpreter
> VMMaker-oscog-EstebanLorenzano.166 uuid:
> 5773fcb9-2982-4507-8a9e-4308ec33731e Nov  6 2012,
> StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.166 uuid:
> 5773fcb9-2982-4507-8a9e-4308ec33731e Nov  6 2012,
> https://git.gitorious.org/cogvm/blessed.git Commit:
> a7bf128cd3b9389e77ea0cdec9a515282926a483 Date: 2012-11-02 14:17:44 +0100
> By: Esteban Lorenzano  Jenkins build #136
> Image: Pharo1.4 [Latest update: #14457]
>
> SerialPort(Object)>>error:
> Receiver: SerialPort(closed, 9600 baud, 8 bits, 1 stopbits, no
> parity)
> Arguments and temporary variables:
> aString:'Cannot open ''/dev/ttyUSB0'''
> Receiver's instance variables:
> port:   nil
> baudRate:   9600
> stopBitsType:   1
> parityType: 0
> dataBits:   8
> outputFlowControlType:  0
> inputFlowControlType:   0
> xOnByte:19
> xOffByte:   24
>
> SerialPort>>openPort:
> Receiver: SerialPort(closed, 9600 baud, 8 bits, 1 stopbits, no
> parity)
> Arguments and temporary variables:
> portId: '/dev/ttyUSB0'
> result: nil
> Receiver's instance variables:
> port:   nil
> baudRate:   9600
> stopBitsType:   1
> parityType: 0
> dataBits:   8
> outputFlowControlType:  0
> inputFlowControlType:   0
> xOnByte:19
> xOffByte:   24
>
> UndefinedObject>>DoIt
> Receiver: nil
> Arguments and temporary variables:
>
> Receiver's instance variables:
> nil
>
> Compiler>>evaluate:in:to:notifying:ifFail:logged:
> Receiver: a Compiler
> Arguments and temporary variables:
> textOrStream:   a ReadWriteStream
> aContext:   nil
> receiver:   nil
> aRequestor: a TextMorphForEditView(464781312)
> failBlock:  [self morph flash.
> ^ nil]
> logFlag:true
> methodNode: DoIt
> sPort := SerialPort new.
> ^ sPort openPort: '/dev/ttyUSB0'
> method: (UndefinedObject>>#DoIt "a
> CompiledMethod(30146560)")
> value:  nil
> toLog:  nil
> itsSelection:   nil
> itsSelectionString: nil
> Receiver's instance variables:
> sourceStream:   a ReadWriteStream
> requestor:  a TextMorphForEditView(464781312)
> class:  UndefinedObject
> category:   nil
> context:nil
> parser: a Parser
>
> [rcvr class evaluatorClass new
> evaluate: self selectionForDoitAsStream
> in: ctxt
> to: rcvr
> notifying: self morph
> ifFail: [self morph flash.
> ^ nil]
> logged: true] in SmalltalkEditor>>evaluateSelectionAndDo:
> Receiver: a SmalltalkEditor
> Arguments and temporary variables:
> rcvr:   nil
> ctxt:   nil
> Receiver's instance variables:
> morph:  a TextMorphForEditView(464781312)
> selectionShowing:   true
> model:  a Workspace
> editingState:   a SmalltalkEditingState
>
>
> This is the code I tried:
>
> sPort := SerialPort new.
> sPort close.
> sPort openPort: '/dev/ttyUSB0'.
>
> Did you tried:

sPort := SerialPort new.
sPort close.
sPort openPort: '/dev/ttyS0'.

 Luc

What can I have done wrong?
>
> If I'm trying the other approach (making a symbolc link to /dev/ttyS0
> I can open the port and get my informations back.
>
> Regards
> Friedrich
>
>
> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>
>

Re: [Pharo-project] Fixing the StackInterpreterSimulator for Pharo 1.4

[Stefan Marr]

Hi:

On 06 Nov 2012, at 17:59, Stéphane Ducasse wrote:

>> The attached change set fixes bit rot in the StackInterpreterSimulator and 
>> related classes.
>> 
>> Here a brief summary:
>> 
>> - VMClass>>#doOrDefer: now uses ProcessBrowser>>#isUIProcess: instead of 
>> Project
>> - it replaces the use of #asDisplayText with StringMorph>>#contents:.
>> - use of ThreadStream>>#on: is replaced with ThreadSafeTranscript>>#new
>> - Utilities is replaced by UIManager>>#default
>> - and #primitiveGetAttribute now uses the non-depricated `Smalltalk vm 
>> getSystemAttribute: attr`

Here are more complete patch.


Fix simulator.3.cs
Description: Binary data


Into which tracker should that go? 
CogVM or Pharo?

Best regards
Stefan


-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

[Pharo-project] [update 2.0] #20386

[Marcus Denker]

[update 2.0] #20386
20386
-

Issue 6933: Fixing the fact that typing ...
http://code.google.com/p/pharo/issues/detail?id=6933

Issue 6853: Monticello merge conflicts on reordered package names
http://code.google.com/p/pharo/issues/detail?id=6853

Issue 6760: Traits dont get repackaged
http://code.google.com/p/pharo/issues/detail?id=6760

Issue 6938: poolDictionaryNames in wrong package
http://code.google.com/p/pharo/issues/detail?id=6938




Diff information:
http://ss3.gemstone.com/ss/Pharo20/Traits-MarcusDenker.442.diff
http://ss3.gemstone.com/ss/Pharo20/NECompletion-MarcusDenker.67.diff
http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.728.diff
http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1236.diff

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

Re: [Pharo-project] Opening a serial Port with Pharo on Linux

[Friedrich Dominicus]

Luc Fabresse  writes:

> Hi Friedrich,
>
>  I did not test myself but I will soon.
>  Since the Jenkins is down, you can found the latest VM (with the SerialPlugin
> modifications that Esteban did) in my dropbox:
> https://www.dropbox.com/sh/flx2cc8mjszhckg/uZ8sTxSB1k
Ok I downloaded this Virtual Machine and tried it, but still the erro
persists:
8 November 2012 5:24:29.474 pm

VM: unix - i686 - linux-gnu - CoInterpreter VMMaker-oscog-EstebanLorenzano.166 
uuid: 5773fcb9-2982-4507-8a9e-4308ec33731e Nov  6 2012, 
StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.166 uuid: 
5773fcb9-2982-4507-8a9e-4308ec33731e Nov  6 2012, 
https://git.gitorious.org/cogvm/blessed.git Commit: 
a7bf128cd3b9389e77ea0cdec9a515282926a483 Date: 2012-11-02 14:17:44 +0100 By: 
Esteban Lorenzano  Jenkins build #136
Image: Pharo1.4 [Latest update: #14457]

SerialPort(Object)>>error:
Receiver: SerialPort(closed, 9600 baud, 8 bits, 1 stopbits, no parity)
Arguments and temporary variables: 
aString:'Cannot open ''/dev/ttyUSB0'''
Receiver's instance variables: 
port:   nil
baudRate:   9600
stopBitsType:   1
parityType: 0
dataBits:   8
outputFlowControlType:  0
inputFlowControlType:   0
xOnByte:19
xOffByte:   24

SerialPort>>openPort:
Receiver: SerialPort(closed, 9600 baud, 8 bits, 1 stopbits, no parity)
Arguments and temporary variables: 
portId: '/dev/ttyUSB0'
result: nil
Receiver's instance variables: 
port:   nil
baudRate:   9600
stopBitsType:   1
parityType: 0
dataBits:   8
outputFlowControlType:  0
inputFlowControlType:   0
xOnByte:19
xOffByte:   24

UndefinedObject>>DoIt
Receiver: nil
Arguments and temporary variables: 

Receiver's instance variables: 
nil

Compiler>>evaluate:in:to:notifying:ifFail:logged:
Receiver: a Compiler
Arguments and temporary variables: 
textOrStream:   a ReadWriteStream
aContext:   nil
receiver:   nil
aRequestor: a TextMorphForEditView(464781312)
failBlock:  [self morph flash.
^ nil]
logFlag:true
methodNode: DoIt
sPort := SerialPort new.
^ sPort openPort: '/dev/ttyUSB0'
method: (UndefinedObject>>#DoIt "a 
CompiledMethod(30146560)")
value:  nil
toLog:  nil
itsSelection:   nil
itsSelectionString: nil
Receiver's instance variables: 
sourceStream:   a ReadWriteStream
requestor:  a TextMorphForEditView(464781312)
class:  UndefinedObject
category:   nil
context:nil
parser: a Parser

[rcvr class evaluatorClass new
evaluate: self selectionForDoitAsStream
in: ctxt
to: rcvr
notifying: self morph
ifFail: [self morph flash.
^ nil]
logged: true] in SmalltalkEditor>>evaluateSelectionAndDo:
Receiver: a SmalltalkEditor
Arguments and temporary variables: 
rcvr:   nil
ctxt:   nil
Receiver's instance variables: 
morph:  a TextMorphForEditView(464781312)
selectionShowing:   true
model:  a Workspace
editingState:   a SmalltalkEditingState


This is the code I tried:

sPort := SerialPort new.
sPort close.
sPort openPort: '/dev/ttyUSB0'.

What can I have done wrong?

If I'm trying the other approach (making a symbolc link to /dev/ttyS0
I can open the port and get my informations back.

Regards
Friedrich


-- 
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim 
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Re: [Pharo-project] [update 2.0] #20385

[Pavel Krivanek]

Automatic CI update jobs startup is not working so I started it manually.

-- Pavel

On Thu, Nov 8, 2012 at 3:41 PM, Marcus Denker  wrote:
> 20385
> -
>
> Issue 6936: Compiler tests dependent on TextMorph
> http://code.google.com/p/pharo/issues/detail?id=6936
>
> Issue 6935: CompilerEvaluationTest dependent on Debugger
> http://code.google.com/p/pharo/issues/detail?id=6935
>
> Issue 6934: move encodeForHTTP tests to own class
> http://code.google.com/p/pharo/issues/detail?id=6934
>
> Issue 6918: Right click on packages over a category without MC 
> corresponding package raises DNU
> http://code.google.com/p/pharo/issues/detail?id=6918
>
>
> Diff information:
> http://ss3.gemstone.com/ss/Pharo20/NetworkTests-MarcusDenker.79.diff
> http://ss3.gemstone.com/ss/Pharo20/CompilerTests-MarcusDenker.127.diff
> http://ss3.gemstone.com/ss/Pharo20/CollectionsTests-MarcusDenker.578.diff
> http://ss3.gemstone.com/ss/Pharo20/CI-Core-MarcusDenker.48.diff
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>

[Pharo-project] What did you guys do to startup-time ?

[Miloslav.Raus]

Who snuffed the poor guy ? I don't know what magic (yea, i know, not just one 
magic, bunch of magix really ;-) you did but ... I downloaded Pharo 2.0 to give 
it a whirl (I love smalltalk and keep playing with it / write an app in it 
every once in a while), unzipped it, doble clicked the binary and the window 
jumped me so fast i nearly fell of my chair (a positive WTF moment ;-).

And not just old Mr. Startup Time, you killed Lady Delay too. I remember squeak 
/ older pharo versions feeling a bit sluggish (a slight delay between clicking 
and the menu popping up / whatever), but now it is blazing fast.

Just saying "Great work" would be an understatement / denigration.

* rausm deeply bows in silent awe

Re: [Pharo-project] unpacking cairo.tgz fails during VM build

[Camillo Bruni]

> 
>> Is this a known issue, or my "tar" install is wrong?
> 
> yes it is known..
> i had to install 7z support for tar.
> this is because MacOS is number of years behind the most recent release of 
> tar,
> which supports 7z compressing by default :)

so that has to be installed on OSX or not?
If we should update the HOWTOBUILD accordingly?

> And with your config, i am not sure that default MacOS installation
> having unxz utility installed.
> If yes, then , of course it makes sense to change config to what is
> proposed by you.
> And if not, then it is better to leave a note in class & methods
> comments to indicate that people should
> install more recent tar utility.

[Pharo-project] [update 2.0] #20385

[Marcus Denker]

20385
-

Issue 6936: Compiler tests dependent on TextMorph
http://code.google.com/p/pharo/issues/detail?id=6936

Issue 6935: CompilerEvaluationTest dependent on Debugger
http://code.google.com/p/pharo/issues/detail?id=6935

Issue 6934: move encodeForHTTP tests to own class
http://code.google.com/p/pharo/issues/detail?id=6934

Issue 6918: Right click on packages over a category without MC 
corresponding package raises DNU
http://code.google.com/p/pharo/issues/detail?id=6918


Diff information:
http://ss3.gemstone.com/ss/Pharo20/NetworkTests-MarcusDenker.79.diff
http://ss3.gemstone.com/ss/Pharo20/CompilerTests-MarcusDenker.127.diff
http://ss3.gemstone.com/ss/Pharo20/CollectionsTests-MarcusDenker.578.diff
http://ss3.gemstone.com/ss/Pharo20/CI-Core-MarcusDenker.48.diff

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

Re: [Pharo-project] Increase memory

[roberto.mine...@usi.ch]

Hi Fernando,

On Nov 8, 2012, at 2:32 PM, Fernando Olivero 
 wrote:

> Ciao Roberto, which is the current size of the image? (the .image file).

The image is indeed fresh, just installed FileSystemGit.. It's about 30 MB..

> If you evaluate the following a couple of times (print it cmd-p), you will 
> cleanup most of the unreferenced objects in the image, it returns a number so 
> you can compare it to successive evaluations.
> 
> Smalltalk garbageCollect.
> 
> You can also follow the pointers to objects, to detect objects which you 
> suspect are just hanging around, and fail to be garbage collected, to clear 
> those references. Open an inspector an any object,and the menu has that 
> option. ( {Object. 1. #hello} inspect) .
> 
> You can also, start with a fresh image.
> 
> 
> pd: if you search the mailing list, i remember Tudor writing about large 
> images and vm's.

Then, I'll look around.. Thanks..

>  
> 
> 
> On Thu, Nov 8, 2012 at 2:16 PM, roberto.mine...@usi.ch 
>  wrote:
> Hi,
> 
> I was executing a piece of code that collects the revisions of a Git repo in 
> Pharo but it seems Pharo requires more memory..
> 
> How do I increase the available memory?
> 
> Here is the log:
> 
> SmalltalkImage>>signalLowSpace
> OutOfMemory>>defaultAction
> UndefinedObject>>handleSignal:
> OutOfMemory(Exception)>>pass
> PasteUpMorph>>becomeActiveDuring: in Block: [:ex | ...
> BlockClosure>>cull:
> MethodContext(ContextPart)>>handleSignal: in Block: [self 
> exceptionHandlerBlock cull: exception]
> BlockClosure>>ensure:
> MethodContext(ContextPart)>>handleSignal:
> MethodContext(ContextPart)>>handleSignal:
> OutOfMemory(Exception)>>signal
> OutOfMemory class(Exception class)>>signal
> ByteArray class(Behavior)>>basicNew:
> ByteArray class(Behavior)>>new:
> ByteArray(SequenceableCollection)>>copyFrom:to:
> ReadStream(PositionableStream)>>contents
> GitPackedNonDelta(GitPackedObject)>>compressedData
> GitPackedNonDelta(GitPackedObject)>>computeCRC
> GitPackedNonDelta(GitPackedObject)>>loadFrom:
> GitPackedObject class>>fromPack:at:in:
> GitPackFile>>objectAtOffset:
> GitPackFile>>objectNamed:
> GitRepository>>packedObjectNamed:ifAbsent: in Block: [:pack | (pack 
> objectNamed: aHexHash)...
> GitRepository>>packsDo: in Block: [:pack | aBlock value: pack]
> OrderedCollection>>do:
> GitRepository>>packsDo:
> GitRepository>>packedObjectNamed:ifAbsent:
> GitRepository>>objectNamed:ifAbsent: in Block: [self packedObjectNamed: aHash 
> ifAbsent: aBlock]
> GitRepository>>looseObjectNamed:ifAbsent: in Block: [^ aBlock value]
> False>>ifTrue:ifFalse:
> 
> Thanks,
> Roberto
> 

Re: [Pharo-project] New command line option: load updates

[Camillo Bruni]

nice! :) 
now we should rewrite the monkey fully in Pharo, given that we have now
almost everything needed that shouldn't be that hard anymore ;)!

On 2012-11-08, at 14:39, Marcus Denker  wrote:

> Hi,
> 
> There is now a command line option to load updates.
> 
> To test it:
> 
> wget --quiet -qO - http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | bash
> 
> ./vm.sh Pharo.image update
> 
> What is does it to load updates, then snapshot and quit.
> 
> The idea is to use this in the new CI setup so we don't need any external 
> scripts.
> 
> --
> Marcus Denker -- http://marcusdenker.de
> 
> 

[Pharo-project] New command line option: load updates

[Marcus Denker]

Hi,

There is now a command line option to load updates.

To test it:

wget --quiet -qO - http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | bash

./vm.sh Pharo.image update

What is does it to load updates, then snapshot and quit.

The idea is to use this in the new CI setup so we don't need any external 
scripts.

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

Re: [Pharo-project] Increase memory

[Alexandre Bergel]

By passing appropriate arguments when launching the VM on the command line.

Cheers,
Alexandre


On Nov 8, 2012, at 10:16 AM, roberto.mine...@usi.ch wrote:

> Hi,
> 
> I was executing a piece of code that collects the revisions of a Git repo in 
> Pharo but it seems Pharo requires more memory..
> 
> How do I increase the available memory?
> 
> Here is the log:
> 
> SmalltalkImage>>signalLowSpace
> OutOfMemory>>defaultAction
> UndefinedObject>>handleSignal:
> OutOfMemory(Exception)>>pass
> PasteUpMorph>>becomeActiveDuring: in Block: [:ex | ...
> BlockClosure>>cull:
> MethodContext(ContextPart)>>handleSignal: in Block: [self 
> exceptionHandlerBlock cull: exception]
> BlockClosure>>ensure:
> MethodContext(ContextPart)>>handleSignal:
> MethodContext(ContextPart)>>handleSignal:
> OutOfMemory(Exception)>>signal
> OutOfMemory class(Exception class)>>signal
> ByteArray class(Behavior)>>basicNew:
> ByteArray class(Behavior)>>new:
> ByteArray(SequenceableCollection)>>copyFrom:to:
> ReadStream(PositionableStream)>>contents
> GitPackedNonDelta(GitPackedObject)>>compressedData
> GitPackedNonDelta(GitPackedObject)>>computeCRC
> GitPackedNonDelta(GitPackedObject)>>loadFrom:
> GitPackedObject class>>fromPack:at:in:
> GitPackFile>>objectAtOffset:
> GitPackFile>>objectNamed:
> GitRepository>>packedObjectNamed:ifAbsent: in Block: [:pack | (pack 
> objectNamed: aHexHash)...
> GitRepository>>packsDo: in Block: [:pack | aBlock value: pack]
> OrderedCollection>>do:
> GitRepository>>packsDo:
> GitRepository>>packedObjectNamed:ifAbsent:
> GitRepository>>objectNamed:ifAbsent: in Block: [self packedObjectNamed: aHash 
> ifAbsent: aBlock]
> GitRepository>>looseObjectNamed:ifAbsent: in Block: [^ aBlock value]
> False>>ifTrue:ifFalse:
> 
> Thanks,
> Roberto

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

Re: [Pharo-project] Increase memory

[Fernando Olivero]

Ciao Roberto, which is the current size of the image? (the .image file).


If you evaluate the following a couple of times (print it cmd-p), you will
cleanup most of the unreferenced objects in the image, it returns a number
so you can compare it to successive evaluations.

Smalltalk garbageCollect.

You can also follow the pointers to objects, to detect objects which you
suspect are just hanging around, and fail to be garbage collected, to clear
those references. Open an inspector an any object,and the menu has that
option. ( {Object. 1. #hello} inspect) .

You can also, start with a fresh image.


pd: if you search the mailing list, i remember Tudor writing about large
images and vm's.



On Thu, Nov 8, 2012 at 2:16 PM, roberto.mine...@usi.ch <
roberto.mine...@usi.ch> wrote:

> Hi,
>
> I was executing a piece of code that collects the revisions of a Git repo
> in Pharo but it seems Pharo requires more memory..
>
> How do I increase the available memory?
>
> Here is the log:
>
> SmalltalkImage>>signalLowSpace
> OutOfMemory>>defaultAction
> UndefinedObject>>handleSignal:
> OutOfMemory(Exception)>>pass
> PasteUpMorph>>becomeActiveDuring: in Block: [:ex | ...
> BlockClosure>>cull:
> MethodContext(ContextPart)>>handleSignal: in Block: [self
> exceptionHandlerBlock cull: exception]
> BlockClosure>>ensure:
> MethodContext(ContextPart)>>handleSignal:
> MethodContext(ContextPart)>>handleSignal:
> OutOfMemory(Exception)>>signal
> OutOfMemory class(Exception class)>>signal
> ByteArray class(Behavior)>>basicNew:
> ByteArray class(Behavior)>>new:
> ByteArray(SequenceableCollection)>>copyFrom:to:
> ReadStream(PositionableStream)>>contents
> GitPackedNonDelta(GitPackedObject)>>compressedData
> GitPackedNonDelta(GitPackedObject)>>computeCRC
> GitPackedNonDelta(GitPackedObject)>>loadFrom:
> GitPackedObject class>>fromPack:at:in:
> GitPackFile>>objectAtOffset:
> GitPackFile>>objectNamed:
> GitRepository>>packedObjectNamed:ifAbsent: in Block: [:pack | (pack
> objectNamed: aHexHash)...
> GitRepository>>packsDo: in Block: [:pack | aBlock value: pack]
> OrderedCollection>>do:
> GitRepository>>packsDo:
> GitRepository>>packedObjectNamed:ifAbsent:
> GitRepository>>objectNamed:ifAbsent: in Block: [self packedObjectNamed:
> aHash ifAbsent: aBlock]
> GitRepository>>looseObjectNamed:ifAbsent: in Block: [^ aBlock value]
> False>>ifTrue:ifFalse:
>
> Thanks,
> Roberto
>

Re: [Pharo-project] Tips for efficient multi-serial handling

[Udo Schneider]

Hi Igor,

thanks for the reply.

The idea working with Semaphore has definitly it's own charm. From my 
last (high-level) check I only found serial primitives which return 0 
bytes if nothing was recieved meanwhile - no Semaphore as far as I saw.


Regarding adding support for this - I try to stay away from the VM (due 
to C - no pun intended!) as far as possible. So I'd rather pay somebody 
who knows his was around in the VM to do it :-) Volunteers?


Best Regards,

Udo


On 08.11.12 05:13, Igor Stasenko wrote:

Sorry, Udo, for quick response.

I think you can do that with Pharo without polling. You just use
semaphores (which directly signaled by OS+VM).
I am not sure about if everything in VM (usb/midi /etc) uses
non-blocking i/o out of the box,
but if you really really want to hake it and ready to pay for it (in
terms of own time (or somebody else's ;) ))
i do not see any impenetrable barriers there.

[Pharo-project] Increase memory

[roberto.mine...@usi.ch]

Hi,

I was executing a piece of code that collects the revisions of a Git repo in 
Pharo but it seems Pharo requires more memory..

How do I increase the available memory?

Here is the log:

SmalltalkImage>>signalLowSpace
OutOfMemory>>defaultAction
UndefinedObject>>handleSignal:
OutOfMemory(Exception)>>pass
PasteUpMorph>>becomeActiveDuring: in Block: [:ex | ...
BlockClosure>>cull:
MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock 
cull: exception]
BlockClosure>>ensure:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
OutOfMemory(Exception)>>signal
OutOfMemory class(Exception class)>>signal
ByteArray class(Behavior)>>basicNew:
ByteArray class(Behavior)>>new:
ByteArray(SequenceableCollection)>>copyFrom:to:
ReadStream(PositionableStream)>>contents
GitPackedNonDelta(GitPackedObject)>>compressedData
GitPackedNonDelta(GitPackedObject)>>computeCRC
GitPackedNonDelta(GitPackedObject)>>loadFrom:
GitPackedObject class>>fromPack:at:in:
GitPackFile>>objectAtOffset:
GitPackFile>>objectNamed:
GitRepository>>packedObjectNamed:ifAbsent: in Block: [:pack | (pack 
objectNamed: aHexHash)...
GitRepository>>packsDo: in Block: [:pack | aBlock value: pack]
OrderedCollection>>do:
GitRepository>>packsDo:
GitRepository>>packedObjectNamed:ifAbsent:
GitRepository>>objectNamed:ifAbsent: in Block: [self packedObjectNamed: aHash 
ifAbsent: aBlock]
GitRepository>>looseObjectNamed:ifAbsent: in Block: [^ aBlock value]
False>>ifTrue:ifFalse:

Thanks,
Roberto

Re: [Pharo-project] NB integration

[Esteban Lorenzano]

yes... but the athens ready VMs are also coming with pharo 2.0 so... 

On Nov 8, 2012, at 4:29 AM, Igor Stasenko  wrote:

> On 2 November 2012 10:07, Esteban Lorenzano  wrote:
>> pharo 2.0 will be "athens ready"... that means NB ready too :)
>> 
> well, i actually thought that we ship "athens-ready" VMs first..
> 
> But as long as we want to put an Athens preview into image.. that will
> also mean having NB loaded into image.
> 
> (hearing chords of  'unnecessary bloating base image size' from afar) :)
> 
> eh.. everything has its cost.
> 
>> On Nov 2, 2012, at 2:00 PM, dimitris chloupis  wrote:
>> 
>> 
>> you got my vote if it is easy enough to do ;)
>> 
>> 
>> From: Torsten Bergmann 
>> To: pharo-project@lists.gforge.inria.fr
>> Sent: Friday, 2 November 2012, 12:15
>> Subject: [Pharo-project] NB integration
>> 
>> AFAIK there was a plan to integrate NativeBoost
>> into Pharo. Is it for 2.0 or 2.1?
>> 
>> I would like to see it for 2.0...
>> 
>> Thx
>> T.
>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] Replace ByteArray with a smaller one

[Mariano Martinez Peck]

On Thu, Nov 8, 2012 at 4:24 AM, Igor Stasenko  wrote:
> On 7 November 2012 11:11, Camillo Bruni  wrote:
>> if the chunks you wan to cut off are big enough you could
>> potentially allocate a new object there which get's gc-ed.
>>
> yes..
> actually you can 'crop' the existing object by modifying its size
> field (so VM will know it)
> and then for the rest bytes, mark them as a 'free chunk', which designates a
> unused memory space in heap.
> actually, this could be a good candidate for a primitive.


Exactlly. I was hoping there was already a primitive for that :(


> But imo, much better strategy is to not allocate too big arrays. :)
>
> Also, as alternative , you can create a 'ArraySlice' collection class,
> which is a view on existing array but with smaller number or elements.
> And pass it around as a valid collection.
>
>> But I have no clue how to do that without VM / NB support ;)
>>

:(


>>
>> On 2012-11-07, at 14:39, Mariano Martinez Peck  wrote:
>>
>>> Hi guys. I have a ByteArray of size N.
>>> And I want now only the same ByteArray but from 1 to N-X. I am using
>>> #copyFrom:to: but that one answers a new copy. If the ByteArray is large,
>>> this takes time because it needs to allocate a large object. In my case I
>>> don't care and I can modify the original ByteArray itself (lets say make it
>>> smaller, null the remaining part and change the object header info). That
>>> way I would avoid an extra allocation. Is there a primitive for that?
>>>
>>> Thanks!
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>



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

Re: [Pharo-project] PluggableListMorph error, how to debug ?

[Henrik Sperre Johansen]

On 04.11.2012 18:37, Benjamin wrote:

In Pharo 1.4, browse Morph
Find the method fullDrawOn:

and replace

on: Error do: [:err |
self setProperty: #errorOnDraw toValue: true.
self setProperty: #drawError toValue: err freeze.
^ self drawErrorOn: aCanvas
]

by:
  value

Now you will have a debugger instead of the red square of death

But do it at you own risk ^^
Ben

Debugging UI code is one of those places you probably want to insert a 
haltOnce instead, or risk losing the image :)


Cheers,
Henry

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

[Camillo Bruni]

On 2012-11-08, at 04:39, Igor Stasenko  wrote:

> sure sure..
> but guys... i really doubt that i would want to see people poking with
> NB who don't even have a
> basic understanding of malloc(ed) memory management and working with
> memory buffers & pointers.
> For such sort of people, best what i can offer is "go back when you
> will learn basics first".

that reads for me: everybody but me should use it.

And you can be pretty sure that most pharoers (including myself) have
a pretty vague notion about malloc/free, combined with the internals
of an third party C library, that makes a pretty unstable field.

Again, no silver bullets here, but less arrogance and more examples!


> Of course, it would be cool if NB could work even for "dummies", but i
> am thinking , as any technology,
> before you start using it without shooting yourself into foot, you
> should do some homework first.

Re: [Pharo-project] Tips for efficient multi-serial handling

[drush66]

Hi Udo!

Well, as fare as I know there is currently no equivalent Ruby's
EventMachine, or similar event based server infrastructure.

There is AioPlugin for async IO http://wiki.squeak.org/squeak/3384 which
lets Smalltalk process (looking from the os view) to get async notifications
of IO events, and signal semaphore which could then be used to activate
sleeping smalltalk process (now I talk about process from the smalltalk VM
view).

This is useful but I think it does not address all of 10ck issues
effectively.

Also:
- I am not sure it works on windows
- I am not sure it can be used for serial ports

In the long run I always wanted to take a stab into something like
EventMachine for Pharo, at least for the basic tcp protocol,  but never got
the time. 

Also Delivering all important protocols on top of it (like HTTP, SMTP, AMQP,
file io, serial, etc, etc) would probably be huge undertaking since most
existing libraries would need considerable amount of love to be used in
evented manner, some maybe even complete new event based versions.





-
http://www.cloud208.com/
--
View this message in context: 
http://forum.world.st/Tips-for-efficient-multi-serial-handling-tp4653104p4654413.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

[Max Leske]

I get your point Igor but then again, we're all somewhat self taught which 
means that as a developer if you don't understand something you hack around 
until you get it. It's not like I'm going to break anything in the released 
products, right? And I think I can judge the risk of wrecking my own machine.

I think that helping each other out on this list is more important than 
scowling at the noobs and yelling "DON'T TOUCH".

Sorry if that comes across harsh but I'm honestly a little upset.

Max


On 08.11.2012, at 04:39, Igor Stasenko  wrote:

> sure sure..
> but guys... i really doubt that i would want to see people poking with
> NB who don't even have a
> basic understanding of malloc(ed) memory management and working with
> memory buffers & pointers.
> For such sort of people, best what i can offer is "go back when you
> will learn basics first".
> 
> Of course, it would be cool if NB could work even for "dummies", but i
> am thinking , as any technology,
> before you start using it without shooting yourself into foot, you
> should do some homework first.
> 
> 
> On 7 November 2012 08:09, Stéphane Ducasse  wrote:
>> + 1
>> 
>> On Nov 7, 2012, at 9:43 AM, Camillo Bruni wrote:
>> 
>>> Just copy paste the thing you posted in the NBBasicExamples and we're
>>> done. A couple of examples which show common problems will help
>>> certainly help people to understand.
>>> 
>>> Plus we should convert the examples into tests so they are always run!
>>> 
>>> On 2012-11-07, at 09:28, Stéphane Ducasse  wrote:
>>> 
 
 On Nov 6, 2012, at 11:06 PM, Igor Stasenko wrote:
 
> On 6 November 2012 17:57, Stéphane Ducasse  
> wrote:
>> This is clearly something to add to the documentation of NativeBoost.
>> Igor can you do it?
> 
> I already have a description of memory management API for NB in docs.
> And telling how manage external memory is... ahem.. not really fits into 
> docs :)
> Maybe a tutor or something.
 
 think not technical but user!
 Id o not give a shit if what helps me is called a doc or a tutorial.
 I care that it helps me fixing my problem.
 And what I see is that the example of Max is a nice example of a recurring 
 problem
 people face.
 
 Stef
> 
> 
> 
> --
> Best regards,
> Igor Stasenko.
> 
 
 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
>