[Pharo-project] Implicit conversions ?

[Sven Van Caekenberghe]

Why is that the following 2 expressions work

#(1 2 3 4 5 6) asByteArray replaceFrom: 1 to: 3 with: 'abc'.
'abcdef' replaceFrom: 1 to: 3 with: #(70 71 72) asByteArray.

while the next 2 don't

(#(70 71 72) asByteArray) at: 1 put: $a; yourself.
'abcdef' at: 1 put: 75; yourself.

and there exists

'abcdef' byteAt: 1 put: 75; yourself.

but there is no

(#(70 71 72) asByteArray) charAt: 1 put: $a; yourself.

Is the implicit conversion in #replaceFrom:to:with: by design ?

And why is there no equivalent single operation ?

Sven

PS: I ran into this trying to deal with the concept of a 'bivalent' stream, one 
that can be read/written both byte and char based, some streams like 
SocketStream support this a little bit, but not really.


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

Re: [Pharo-project] Another silent failure?

[Schwab,Wilhelm K]

Levente,

FFI, Linux.  The point is that the code fails silently when given a string and 
performs as expected when given a byte array.  That is all the more unusual 
given that the pointer is typed as char* (if anything, I would expect the 
string to succeed).  Just a hunch at this point, it sure looks like something 
that goes wrong "down in the depths" and it does nothing rather than reporting 
an error.  My question should have been clear (Guillermo obviously got it): 
does anyone else consider that combination of behaviors to be a problem?  
Silent failures are the order of the day in Squeak; I hope we will eliminate 
them in Pharo.

Yes, I can package and release the code.  Whether that will take the form of a 
quick example of what I suspect is a long-standing defect in FFI or a nice 
wrapper around PLplot will depend on how PLplot performs.

Windows device contexts are proving difficult to replace.  Otherwise, Microsoft 
can keep the OS.

Bill






From: pharo-project-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi 
[le...@elte.hu]
Sent: Wednesday, September 15, 2010 10:01 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another silent failure?

On Wed, 15 Sep 2010, Schwab,Wilhelm K wrote:

> I am interested in the opinions of helpful people who might have something 
> constructive to add.

Sorry, but don't expect any help with this attitude. Even the most helpful
people - like Henrik - can't help you, because you don't give enough
information about your problem.

Which platform do you use?
Which VM/image do you use?
What's the library you'd like to use?
Is #cPlgver: an FFI call or do you use Alien? Maybe something else?
What's the type of the argument it expects?
If it calls a library function, does it store the pointer you're passing
to it?
Can you share your code?


Levente

>
>
>
> 
> From: pharo-project-boun...@lists.gforge.inria.fr 
> [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik Johansen 
> [henrik.s.johan...@veloxit.no]
> Sent: Wednesday, September 15, 2010 6:18 PM
> To: Pharo-project@lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Another silent failure?
>
> How do you expect us to help you debug this?
> Really?
>
> Cheers,
> Henry
>
> On Sep 15, 2010, at 8:45 38PM, Schwab,Wilhelm K wrote:
>
>> I am playing with a new library and for kicks thought I would call its 
>> get-version function:
>>
>> | buffer |
>> buffer := String new:80.
>> PLplotLibrary default cPlgver:buffer.
>> buffer.
>>
>> The above appears to do nothing; the buffer remains blank, and there is no 
>> error raised from it.  I tried something more complicated involving external 
>> address and #alloc: and got the version number.  That is encouraging from a 
>> perspective of talking to the library, but then I had to square the above 
>> failure with my use of memcpy() not long ago (different topic).  In that 
>> case, I had real need to allocate a buffer in a fixed heap, but was told 
>> that I could ultimately copy from said buffer (which lives across multiple 
>> gcs and would move) into a ByteArray of the needed size, which would not 
>> move during the memcpy() call.  That worked.  So I tried
>>
>> | buffer |
>> buffer := ByteArray new:80.
>> PLplotLibrary default cPlgver:buffer.
>> buffer asString.
>>
>> and get the version number.  What's up?  Why is it ok to pass a byte array 
>> but not a string?  If there really is a difference, there should be an 
>> exception hinting that something is wrong and what it might be - right?
>>
>> Bill
>>
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

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

Re: [Pharo-project] Another silent failure?

[Levente Uzonyi]

On Wed, 15 Sep 2010, Schwab,Wilhelm K wrote:


I am interested in the opinions of helpful people who might have something 
constructive to add.


Sorry, but don't expect any help with this attitude. Even the most helpful 
people - like Henrik - can't help you, because you don't give enough 
information about your problem.


Which platform do you use?
Which VM/image do you use?
What's the library you'd like to use?
Is #cPlgver: an FFI call or do you use Alien? Maybe something else?
What's the type of the argument it expects?
If it calls a library function, does it store the pointer you're passing 
to it?

Can you share your code?


Levente






From: pharo-project-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik Johansen 
[henrik.s.johan...@veloxit.no]
Sent: Wednesday, September 15, 2010 6:18 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another silent failure?

How do you expect us to help you debug this?
Really?

Cheers,
Henry

On Sep 15, 2010, at 8:45 38PM, Schwab,Wilhelm K wrote:


I am playing with a new library and for kicks thought I would call its 
get-version function:

| buffer |
buffer := String new:80.
PLplotLibrary default cPlgver:buffer.
buffer.

The above appears to do nothing; the buffer remains blank, and there is no 
error raised from it.  I tried something more complicated involving external 
address and #alloc: and got the version number.  That is encouraging from a 
perspective of talking to the library, but then I had to square the above 
failure with my use of memcpy() not long ago (different topic).  In that case, 
I had real need to allocate a buffer in a fixed heap, but was told that I could 
ultimately copy from said buffer (which lives across multiple gcs and would 
move) into a ByteArray of the needed size, which would not move during the 
memcpy() call.  That worked.  So I tried

| buffer |
buffer := ByteArray new:80.
PLplotLibrary default cPlgver:buffer.
buffer asString.

and get the version number.  What's up?  Why is it ok to pass a byte array but 
not a string?  If there really is a difference, there should be an exception 
hinting that something is wrong and what it might be - right?

Bill



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



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

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



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

Re: [Pharo-project] Another silent failure?

[Schwab,Wilhelm K]

Guillermo,

I too was taught (more by life than formal education) that things should 
clearly succeed or fail, but that's not what is happening here, unless I am 
missing something really obvious.

Thanks!

Bill



From: pharo-project-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Guillermo Polito 
[guillermopol...@gmail.com]
Sent: Wednesday, September 15, 2010 9:38 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another silent failure?

On Wed, Sep 15, 2010 at 3:45 PM, Schwab,Wilhelm K 
mailto:bsch...@anest.ufl.edu>> wrote:
I am playing with a new library and for kicks thought I would call its 
get-version function:

| buffer |
buffer := String new:80.
PLplotLibrary default cPlgver:buffer.
buffer.

The above appears to do nothing; the buffer remains blank, and there is no 
error raised from it.  I tried something more complicated involving external 
address and #alloc: and got the version number.  That is encouraging from a 
perspective of talking to the library, but then I had to square the above 
failure with my use of memcpy() not long ago (different topic).  In that case, 
I had real need to allocate a buffer in a fixed heap, but was told that I could 
ultimately copy from said buffer (which lives across multiple gcs and would 
move) into a ByteArray of the needed size, which would not move during the 
memcpy() call.  That worked.  So I tried

| buffer |
buffer := ByteArray new:80.
PLplotLibrary default cPlgver:buffer.
buffer asString.

and get the version number.  What's up?  Why is it ok to pass a byte array but 
not a string?  If there really is a difference, there should be an exception 
hinting that something is wrong and what it might be - right?

I was taught that when objects can't answer a message the right way, they 
should raise an exception :).

BTW, I don't know the difference between ByteArray and String... so I have to 
do some research :)


Bill



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


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

Re: [Pharo-project] Another silent failure?

[Guillermo Polito]

On Wed, Sep 15, 2010 at 3:45 PM, Schwab,Wilhelm K wrote:

> I am playing with a new library and for kicks thought I would call its
> get-version function:
>
> | buffer |
> buffer := String new:80.
> PLplotLibrary default cPlgver:buffer.
> buffer.
>
> The above appears to do nothing; the buffer remains blank, and there is no
> error raised from it.  I tried something more complicated involving external
> address and #alloc: and got the version number.  That is encouraging from a
> perspective of talking to the library, but then I had to square the above
> failure with my use of memcpy() not long ago (different topic).  In that
> case, I had real need to allocate a buffer in a fixed heap, but was told
> that I could ultimately copy from said buffer (which lives across multiple
> gcs and would move) into a ByteArray of the needed size, which would not
> move during the memcpy() call.  That worked.  So I tried
>
> | buffer |
> buffer := ByteArray new:80.
> PLplotLibrary default cPlgver:buffer.
> buffer asString.
>
> and get the version number.  What's up?  Why is it ok to pass a byte array
> but not a string?  If there really is a difference, there should be an
> exception hinting that something is wrong and what it might be - right?
>

I was taught that when objects can't answer a message the right way, they
should raise an exception :).

BTW, I don't know the difference between ByteArray and String... so I have
to do some research :)


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

Re: [Pharo-project] Another silent failure?

[Schwab,Wilhelm K]

I am interested in the opinions of helpful people who might have something 
constructive to add.




From: pharo-project-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Henrik Johansen 
[henrik.s.johan...@veloxit.no]
Sent: Wednesday, September 15, 2010 6:18 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another silent failure?

How do you expect us to help you debug this?
Really?

Cheers,
Henry

On Sep 15, 2010, at 8:45 38PM, Schwab,Wilhelm K wrote:

> I am playing with a new library and for kicks thought I would call its 
> get-version function:
>
> | buffer |
> buffer := String new:80.
> PLplotLibrary default cPlgver:buffer.
> buffer.
>
> The above appears to do nothing; the buffer remains blank, and there is no 
> error raised from it.  I tried something more complicated involving external 
> address and #alloc: and got the version number.  That is encouraging from a 
> perspective of talking to the library, but then I had to square the above 
> failure with my use of memcpy() not long ago (different topic).  In that 
> case, I had real need to allocate a buffer in a fixed heap, but was told that 
> I could ultimately copy from said buffer (which lives across multiple gcs and 
> would move) into a ByteArray of the needed size, which would not move during 
> the memcpy() call.  That worked.  So I tried
>
> | buffer |
> buffer := ByteArray new:80.
> PLplotLibrary default cPlgver:buffer.
> buffer asString.
>
> and get the version number.  What's up?  Why is it ok to pass a byte array 
> but not a string?  If there really is a difference, there should be an 
> exception hinting that something is wrong and what it might be - right?
>
> Bill
>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

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

Re: [Pharo-project] Another silent failure?

[Henrik Johansen]

How do you expect us to help you debug this?
Really?

Cheers,
Henry

On Sep 15, 2010, at 8:45 38PM, Schwab,Wilhelm K wrote:

> I am playing with a new library and for kicks thought I would call its 
> get-version function:
> 
> | buffer |
> buffer := String new:80.
> PLplotLibrary default cPlgver:buffer.
> buffer.
> 
> The above appears to do nothing; the buffer remains blank, and there is no 
> error raised from it.  I tried something more complicated involving external 
> address and #alloc: and got the version number.  That is encouraging from a 
> perspective of talking to the library, but then I had to square the above 
> failure with my use of memcpy() not long ago (different topic).  In that 
> case, I had real need to allocate a buffer in a fixed heap, but was told that 
> I could ultimately copy from said buffer (which lives across multiple gcs and 
> would move) into a ByteArray of the needed size, which would not move during 
> the memcpy() call.  That worked.  So I tried
> 
> | buffer |
> buffer := ByteArray new:80.
> PLplotLibrary default cPlgver:buffer.
> buffer asString.
> 
> and get the version number.  What's up?  Why is it ok to pass a byte array 
> but not a string?  If there really is a difference, there should be an 
> exception hinting that something is wrong and what it might be - right?
> 
> Bill
> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] [squeak-dev] RFB Server not working on Squeak 4.1?

[Lawson English]

 On 9/15/10 2:32 PM, Levente Uzonyi wrote:

On Wed, 15 Sep 2010, Lawson English wrote:

Someone pointed out to me a workaround for this issue. Apparently the 
only way any client (including the Squeak RFBClient) will work with 
the RFBServer in Squeak 4.1 is if you set the client to only accept 
rawEncoding.


ZRLE works fine, but you have to enable it on the server and set your 
client's encoding to ZRLE only.



Levente



Thanks. A change in behavior I didn't know how to cope with (until now).

Lawson


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

Re: [Pharo-project] [squeak-dev] RFB Server not working on Squeak 4.1?

[Levente Uzonyi]

On Wed, 15 Sep 2010, Lawson English wrote:

Someone pointed out to me a workaround for this issue. Apparently the only 
way any client (including the Squeak RFBClient) will work with the RFBServer 
in Squeak 4.1 is if you set the client to only accept rawEncoding.


ZRLE works fine, but you have to enable it on the server and set your 
client's encoding to ZRLE only.



Levente



Works fine at that point, but is likely a bit slower than it could be.

Thanks to all that responded.


Lawson

On 9/8/10 7:30 AM, Lawson English wrote:
 Has anyone tested the RFB server class in Squeak 4.1? I can't get it to 
work in Mac OS X 10.6 or in at least variant of Linux.

Haven't tested it in Pharo.

Lawson





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



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

Re: [Pharo-project] [squeak-dev] RFB Server not working on Squeak 4.1?

[Lawson English]

 Someone pointed out to me a workaround for this issue. Apparently the 
only way any client (including the Squeak RFBClient) will work with the 
RFBServer in Squeak 4.1 is if you set the client to only accept rawEncoding.


Works fine at that point, but is likely a bit slower than it could be.

Thanks to all that responded.


Lawson

On 9/8/10 7:30 AM, Lawson English wrote:
 Has anyone tested the RFB server class in Squeak 4.1? I can't get it 
to work in Mac OS X 10.6 or in at least variant of Linux.

Haven't tested it in Pharo.

Lawson





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

[Pharo-project] Another silent failure?

[Schwab,Wilhelm K]

I am playing with a new library and for kicks thought I would call its 
get-version function:

| buffer |
buffer := String new:80.
PLplotLibrary default cPlgver:buffer.
buffer.

The above appears to do nothing; the buffer remains blank, and there is no 
error raised from it.  I tried something more complicated involving external 
address and #alloc: and got the version number.  That is encouraging from a 
perspective of talking to the library, but then I had to square the above 
failure with my use of memcpy() not long ago (different topic).  In that case, 
I had real need to allocate a buffer in a fixed heap, but was told that I could 
ultimately copy from said buffer (which lives across multiple gcs and would 
move) into a ByteArray of the needed size, which would not move during the 
memcpy() call.  That worked.  So I tried

| buffer |
buffer := ByteArray new:80.
PLplotLibrary default cPlgver:buffer.
buffer asString.

and get the version number.  What's up?  Why is it ok to pass a byte array but 
not a string?  If there really is a difference, there should be an exception 
hinting that something is wrong and what it might be - right?

Bill



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

Re: [Pharo-project] Metacello repositories in the future

[Miguel Enrique Cobá Martínez]

El mié, 15-09-2010 a las 15:52 +0200, Torsten Bergmann escribió:
> One thing I think that should be discussed at ESUG
> (sorry I'm not there) is if and how we want to maintain
> Metacello repositories for the different Pharo versions
> in the future.
> 
> I still think about the project/repo dependency issue:
> 
> An example: we have a repo for Pharo 1.2:
> 
>  MetaRepoForPharo12   it may contain a ConfigurationOfFFI that works
>   for Pharo 1.1. and loads FFI.
>   it may also contain a ConfigurationOfExternalBrowser
>   that requires the ConfigurationOfFFI (usual Metacello 
> project
>   dependency)
> 
> When Pharo 1.3 comes out we have a new MetaRepoForPharo13 and may just
> copy ConfigurationOfFFI over since it only loads packages and these packages
> may be compatible to Pharo 1.3. So far so good ... but:
> 
> What about ConfigurationOfExternalBrowser, if we just copy it to the
> new repo the config still points to the "old" ConfigurationOfFFI in the old 
> MetaRepoForPharo12 repo and not to the new one in MetaRepoForPharo13.
> 
> So we will have to adopt the configs for any new platform version ...
> and since world keeps spinnning we may also end up with forked 
> configurations.  

Yes, that is expected. Mariano proposed some script that
programmatically rewrites a configuration fixin and repointing
dependencies to the new repository. This could be triggered when
creating a new Repo and when automatically copying every configuration
from the previous repo to the new repo.

Cheers
-- 
Miguel Cobá
http://miguel.leugim.com.mx


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

[Pharo-project] Metacello repositories in the future

[Torsten Bergmann]

One thing I think that should be discussed at ESUG
(sorry I'm not there) is if and how we want to maintain
Metacello repositories for the different Pharo versions
in the future.

I still think about the project/repo dependency issue:

An example: we have a repo for Pharo 1.2:

 MetaRepoForPharo12   it may contain a ConfigurationOfFFI that works
  for Pharo 1.1. and loads FFI.
  it may also contain a ConfigurationOfExternalBrowser
  that requires the ConfigurationOfFFI (usual Metacello 
project
  dependency)

When Pharo 1.3 comes out we have a new MetaRepoForPharo13 and may just
copy ConfigurationOfFFI over since it only loads packages and these packages
may be compatible to Pharo 1.3. So far so good ... but:

What about ConfigurationOfExternalBrowser, if we just copy it to the
new repo the config still points to the "old" ConfigurationOfFFI in the old 
MetaRepoForPharo12 repo and not to the new one in MetaRepoForPharo13.

So we will have to adopt the configs for any new platform version ...
and since world keeps spinnning we may also end up with forked configurations.  

Bye
T.


-- 
GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl

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

Re: [Pharo-project] [ANN] Reef now first class citizen on SqueakSource

[Esteban Lorenzano]

Hi,
Yes, I started to work on the (tiny) tutorial, but it will be ready 
next days... please be patient (I'm sorry for the improvisation of the 
announcement, I'll fix that with the tutorial and a little bit more of 
documentation very soon).


Cheers,
Esteban

On 2010-09-15 11:30:03 +0200, Stéphane Ducasse 
 said:


The idea is that you have components that wrap completely the handling 
of Javascript and you can define/control

callback (client or server).
Esteban we need a tutorial :) He knows it :)

On Sep 15, 2010, at 11:10 AM, Torsten Bergmann wrote:


Can you give a short intro/howto or example?

Thx
T.
--
GRATIS: Spider-Man 1-3 sowie 300 weitere Videos!
Jetzt freischalten! http://portal.gmx.net/de/go/maxdome

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





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

Re: [Pharo-project] [ANN] Reef now first class citizen on SqueakSource

[Stéphane Ducasse]

A component model in which you can embed seaside component and be embedded in 
Seaside component 
and the components have javascript client side behavior so you do not have to 
type the javascript invocation
as in plain seaside.

Stef



> Hello,
> 
> Can you write little description abount Reef?
> 
> 2010/9/15 Esteban Lorenzano 
> Reef
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] Monticello Wine?

[Noury Bouraqadi]

Wasn't aware of it.
The article seems to have been remove for some reason (the second link isn't 
working)

Noury @ ESUG 2010 - Barcelona :-)
---
18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, 
Spain.
http://www.esug.org/Conferences/2010




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

Re: [Pharo-project] [ANN] Reef now first class citizen on SqueakSource

[Denis Kudriashov]

Hello,

Can you write little description abount Reef?

2010/9/15 Esteban Lorenzano 

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

[Pharo-project] Monticello Wine?

[Torsten Bergmann]

Did you read my blog post [1]?
According to [2] (german) there is also a wine called "Smalltalk".

Bye
T.

[1] http://astares.blogspot.com/2010/08/smalltalk-and-wine.html
[2] http://www.wiesbadener-kurier.de/region/rheingau/geisenheim/9199613.htm
-- 
GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl

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

[Pharo-project] Monticello Wine?

[Noury Bouraqadi]

Last night while having dinner in a local restaurant, Sean noticed the wine 
label ;-)
http://www.flickr.com/photos/30234...@n02/sets/72157624960714450/

Noury @ ESUG 2010 - Barcelona :-)
---
18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, 
Spain.
http://www.esug.org/Conferences/2010




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

Re: [Pharo-project] [ANN] Reef now first class citizen on SqueakSource

[Stéphane Ducasse]

The idea is that you have components that wrap completely the handling of 
Javascript and you can define/control
callback (client or server).
Esteban we need a tutorial :) He knows it :)

On Sep 15, 2010, at 11:10 AM, Torsten Bergmann wrote:

> Can you give a short intro/howto or example?
> 
> Thx
> T.
> -- 
> GRATIS: Spider-Man 1-3 sowie 300 weitere Videos!
> Jetzt freischalten! http://portal.gmx.net/de/go/maxdome
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] Some thoughts...

[Stéphane Ducasse]

nativeBoost too :)

Stef

On Sep 15, 2010, at 11:08 AM, Tudor Girba wrote:

> Indeed, this sounds really exciting.
> 
> Doru
> 
> 
> On 14 Sep 2010, at 17:59, Stéphane Ducasse wrote:
> 
>> thanks alex :)
>> We will
>> 
>> Stef
>> 
>>> Hi,
>>> 
>>> I really would like to see projects like Opal and Ocean happening. Even 
>>> though I may not have the time to directly contribute to them, they are 
>>> important and I will use them. I am struggling these days to instrument the 
>>> whole Pharo image and this is not easy. I am eagerly waiting for Opal. I 
>>> got burned in the past with networks. 
>>> 
>>> So, please continue...
>>> 
>>> Cheers,
>>> Alexandre
>>> -- 
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> --
> www.tudorgirba.com
> 
> "Yesterday is a fact.
> Tomorrow is a possibility.
> Today is a challenge."
> 
> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] % of unused objects?

[Mariano Martinez Peck]

On Tue, Sep 14, 2010 at 2:46 PM, Alexandre Bergel wrote:

> Hi Mariano,
>
> I also would like to know what is the % of unused objects in my
> applications. How can I do it?
>
>
Hi Alexandre. Sorry I didn't answer before...I don't read emails while ESUG
;)

First, you need an specific modified VM. I can send it by email or upload it
somewhere if you want.

To get that statistics and some more, you have to download the package
UnusedObject  from  http://www.squeaksource.com/UsedObjects

Check the class UnusedObjectDiscoverer and its tests. But basically the idea
is this:

You first evaluate  "UnusedObjectDiscoverer current startDiscovery."

Once that is doneis your time to do what you want to analyzerun
tests, open a workspace, do whatever you want. When you are done, inspect or
print the result of: "UnusedObjectDiscoverer current
stopDiscoveryAndGetStadistics "

And that's all for the moment ;)

Ahhh I did some Moose DistributionMap if you want. For that you need to load
also the package UsedObjectsMoose on a Moose image, and run the class side
examples of the class UsedObjectsDistributionMap

Last thing: I condiser an object was used, when it received  at least one
message.

Cheers

Mariano



> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Esug-list] [squeak-dev] ESUG Awards

[Noury Bouraqadi]

Since the server was blocked for some time, the ESUG board decided to postpone 
the end of votes to the afternoon.
So, you have until 3pm Barcelona time for voting.

Sorry for the inconvenience,
Noury
On 15 sept. 2010, at 11:09, stephane ducasse wrote:

> This is fixed sorry for the mess.
> 
> Stef
> 
> On Sep 15, 2010, at 10:41 AM, Jorge Ressia wrote:
> 
>> Hi Noury,
>> 
>> It seems that the survey is already closed.
>> Is this ok?
>> 
>> Cheers,
>> 
>> 
>> 
>> On Wed, Sep 15, 2010 at 10:17 AM, Noury Bouraqadi  
>> wrote:
>>> Hi,
>>> 
>>> This evening we'll announce the winners for the Tech Awards, and the Book 
>>> Awards.
>>> For the Tech Awards, the conference participants did voted monday after the 
>>> demos.
>>> For the Book Awards, you still can vote on-line untill 12pm (Barcelona 
>>> Time).
>>> http://www.surveymonkey.com/s/Q2LKKDT
>>> 
>>> Best,
>>> Noury @ ESUG 2010 - Barcelona :-)
>>> ---
>>> 18th International Smalltalk Joint Conference, September 13 -17 2010 
>>> Barcelona, Spain.
>>> http://www.esug.org/Conferences/2010
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Jorge Ressia
>> www.jorgeressia.com
>> 
> 
> 
> ___
> Esug-list mailing list
> esug-l...@lists.esug.org
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Noury @ ESUG 2010 - Barcelona :-)
---
18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, 
Spain.
http://www.esug.org/Conferences/2010




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

[Pharo-project] [ANN] Reef now first class citizen on SqueakSource

[Torsten Bergmann]

Can you give a short intro/howto or example?

Thx
T.
-- 
GRATIS: Spider-Man 1-3 sowie 300 weitere Videos!
Jetzt freischalten! http://portal.gmx.net/de/go/maxdome

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

Re: [Pharo-project] Some thoughts...

[Tudor Girba]

Indeed, this sounds really exciting.

Doru


On 14 Sep 2010, at 17:59, Stéphane Ducasse wrote:

> thanks alex :)
> We will
> 
> Stef
> 
>> Hi,
>> 
>> I really would like to see projects like Opal and Ocean happening. Even 
>> though I may not have the time to directly contribute to them, they are 
>> important and I will use them. I am struggling these days to instrument the 
>> whole Pharo image and this is not easy. I am eagerly waiting for Opal. I got 
>> burned in the past with networks. 
>> 
>> So, please continue...
>> 
>> Cheers,
>> Alexandre
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
www.tudorgirba.com

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




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

Re: [Pharo-project] [squeak-dev] ESUG Awards

[Jorge Ressia]

Hi Noury,

It seems that the survey is already closed.
Is this ok?

Cheers,



On Wed, Sep 15, 2010 at 10:17 AM, Noury Bouraqadi  wrote:
> Hi,
>
> This evening we'll announce the winners for the Tech Awards, and the Book 
> Awards.
> For the Tech Awards, the conference participants did voted monday after the 
> demos.
> For the Book Awards, you still can vote on-line untill 12pm (Barcelona Time).
> http://www.surveymonkey.com/s/Q2LKKDT
>
> Best,
> Noury @ ESUG 2010 - Barcelona :-)
> ---
> 18th International Smalltalk Joint Conference, September 13 -17 2010 
> Barcelona, Spain.
> http://www.esug.org/Conferences/2010
>
>
>
>
>



-- 
Jorge Ressia
www.jorgeressia.com

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

[Pharo-project] ESUG Awards

[Noury Bouraqadi]

Hi,

This evening we'll announce the winners for the Tech Awards, and the Book 
Awards.
For the Tech Awards, the conference participants did voted monday after the 
demos.
For the Book Awards, you still can vote on-line untill 12pm (Barcelona Time).
http://www.surveymonkey.com/s/Q2LKKDT

Best,
Noury @ ESUG 2010 - Barcelona :-)
---
18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, 
Spain.
http://www.esug.org/Conferences/2010




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

Re: [Pharo-project] [ANN] Reef now first class citizen on SqueakSource

[Stéphane Ducasse]

cool :)

Stef

On Sep 15, 2010, at 9:13 AM, Esteban Lorenzano wrote:

> Hi,
> Due to the interest demonstrated on Reef, I'm promoting it to it's own place 
> in SqueakSource. 
> You can now download it by executing: 
> 
> Gofer it
>   squeaksource: 'Reef';
>   package: 'Reef';
>   load.
> 
> Cheers,
> Esteban
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

[Pharo-project] [ANN] Reef now first class citizen on SqueakSource

[Esteban Lorenzano]

Hi,
Due to the interest demonstrated on Reef, I'm promoting it to it's own place in 
SqueakSource. 
You can now download it by executing: 

Gofer it
squeaksource: 'Reef';
package: 'Reef';
load.

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