Smalltalk › Pharo › Pharo Smalltalk Developers

What we do with: "Embed source code for methods which get uninstalled from their classes" ???

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Mariano Martinez Peck

What we do with: "Embed source code for methods which get uninstalled from their classes" ???

So....we used to have arround CM instances wrong. There was a problem with the trailer and we fix it. http://code.google.com/p/pharo/issues/detail?id=4186

Then we did: http://code.google.com/p/pharo/issues/detail?id=4192

and, dev image took hous to finish: http://code.google.com/p/pharo/issues/detail?id=4200

because the Compiler recompileAll take ages because of the becomeFordward: it does for the #dropSourcePointer

then igor solve it, it took less time, but we start to loose the source pointer of COmpiledMethods while loading stuff from MC.

in addition, objects as methods started to fail because they do not implement #dropSourcePointer: http://code.google.com/p/pharo/issues/detail?id=4195

so...al users of #run:with:in: should also be broken now, like TestCoverage, etc....

so...what do we do? I would like to:

1) have a fast/normal recompileAll
2) not to loose source code

If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this.

Cheers

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

Marcus Denker-4

Re: What we do with: "Embed source code for methods which get uninstalled from their classes" ???

On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote:
>
> 1) have a fast/normal recompileAll
> 2) not to loose source code
>
> If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this.
>
I think we should roll back the change for now...

All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even
on last year's cell phone 20 times larger than our complete system...)

Marcus

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

Mariano Martinez Peck

Re: What we do with: "Embed source code for methods which get uninstalled from their classes" ???

Me too. I would rollback until we have a better solution and very well tested. I think right now the consequences and worst than the original problem.

On Fri, May 13, 2011 at 8:46 AM, Marcus Denker <[hidden email]> wrote:

On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote:
>
> 1) have a fast/normal recompileAll
> 2) not to loose source code
>
> If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this.
>

I think we should roll back the change for now...

All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even
on last year's cell phone 20 times larger than our complete system...)

Marcus

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

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

Stéphane Ducasse

Re: What we do with: "Embed source code for methods which get uninstalled from their classes" ???

Yes sync with igor

Stef

On May 13, 2011, at 10:47 AM, Mariano Martinez Peck wrote:

> Me too. I would rollback until we have a better solution and very well tested. I think right now the consequences and worst than the original problem.
>
> On Fri, May 13, 2011 at 8:46 AM, Marcus Denker <[hidden email]> wrote:
>
> On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote:
> >
> > 1) have a fast/normal recompileAll
> > 2) not to loose source code
> >
> > If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this.
> >
> I think we should roll back the change for now...
>
> All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even
> on last year's cell phone 20 times larger than our complete system...)
>
> Marcus
>
> --
> Marcus Denker -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

FDominicus

Smalltalk and LibreOffice or OpenOffice

Just wondering if anyone has used Smalltalk for "scripting" this office
Suite. The only I could find about it was VASmalltalk bindings dated
back to 2008....

Regards
Friedrich

Jan van de Sandt

Re: Smalltalk and LibreOffice or OpenOffice

The VA Smalltalk bindings were developed by Marten Feldtmann [1] and the code is available at VAStGoodies.com [2]

Jan.

[1] http://schrievkrom.wordpress.com
[2] http://vastgoodies.com/maps/MSKOOoExamplesAndIDE

On Fri, May 13, 2011 at 2:38 PM, Friedrich Dominicus <[hidden email]> wrote:

Just wondering if anyone has used Smalltalk for "scripting" this office
Suite. The only I could find about it was VASmalltalk bindings dated
back to 2008....

Regards
Friedrich

Igor Stasenko

Re: What we do with: "Embed source code for methods which get uninstalled from their classes" ???

In reply to this post by Stéphane Ducasse

Yes. Just remove sends of #dropSourcePointer. Everything else works fine.

On 13 May 2011 13:09, Stéphane Ducasse <[hidden email]> wrote:

> Yes sync with igor
>
> Stef
>
> On May 13, 2011, at 10:47 AM, Mariano Martinez Peck wrote:
>
>> Me too. I would rollback until we have a better solution and very well tested. I think right now the consequences and worst than the original problem.
>>
>> On Fri, May 13, 2011 at 8:46 AM, Marcus Denker <[hidden email]> wrote:
>>
>> On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote:
>> >
>> > 1) have a fast/normal recompileAll
>> > 2) not to loose source code
>> >
>> > If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this.
>> >
>> I think we should roll back the change for now...
>>
>> All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even
>> on last year's cell phone 20 times larger than our complete system...)
>>
>> Marcus
>>
>> --
>> Marcus Denker -- http://www.marcusdenker.de
>> INRIA Lille -- Nord Europe. Team RMoD.
>>
>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Mariano Martinez Peck

Re: What we do with: "Embed source code for methods which get uninstalled from their classes" ???

Ok. I will do it tonight.

Thanks

On Fri, May 13, 2011 at 3:07 PM, Igor Stasenko <[hidden email]> wrote:

Yes. Just remove sends of #dropSourcePointer. Everything else works fine.

On 13 May 2011 13:09, Stéphane Ducasse <[hidden email]> wrote:
> Yes sync with igor
>
> Stef
>
> On May 13, 2011, at 10:47 AM, Mariano Martinez Peck wrote:
>
>> Me too. I would rollback until we have a better solution and very well tested. I think right now the consequences and worst than the original problem.
>>
>> On Fri, May 13, 2011 at 8:46 AM, Marcus Denker <[hidden email]> wrote:
>>
>> On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote:
>> >
>> > 1) have a fast/normal recompileAll
>> > 2) not to loose source code
>> >
>> > If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this.
>> >
>> I think we should roll back the change for now...
>>
>> All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even
>> on last year's cell phone 20 times larger than our complete system...)
>>
>> Marcus
>>
>> --
>> Marcus Denker -- http://www.marcusdenker.de
>> INRIA Lille -- Nord Europe. Team RMoD.
>>
>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

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

Marcus Denker-4

Re: What we do with: "Embed source code for methods which get uninstalled from their classes" ???

In reply to this post by Igor Stasenko

On May 13, 2011, at 3:13 PM, Mariano Martinez Peck wrote:

> Ok. I will do it tonight.
>

I will do it now ;-)

> Thanks
>
> On Fri, May 13, 2011 at 3:07 PM, Igor Stasenko <[hidden email]> wrote:
> Yes. Just remove sends of #dropSourcePointer. Everything else works fine.
>
>
> On 13 May 2011 13:09, Stéphane Ducasse <[hidden email]> wrote:
> > Yes sync with igor
> >
> > Stef
> >
> > On May 13, 2011, at 10:47 AM, Mariano Martinez Peck wrote:
> >
> >> Me too. I would rollback until we have a better solution and very well tested. I think right now the consequences and worst than the original problem.
> >>
> >> On Fri, May 13, 2011 at 8:46 AM, Marcus Denker <[hidden email]> wrote:
> >>
> >> On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote:
> >> >
> >> > 1) have a fast/normal recompileAll
> >> > 2) not to loose source code
> >> >
> >> > If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this.
> >> >
> >> I think we should roll back the change for now...
> >>
> >> All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even
> >> on last year's cell phone 20 times larger than our complete system...)
> >>
> >> Marcus
> >>
> >> --
> >> Marcus Denker -- http://www.marcusdenker.de
> >> INRIA Lille -- Nord Europe. Team RMoD.
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Mariano
> >> http://marianopeck.wordpress.com
> >>
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

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

cbc

Re: Smalltalk and LibreOffice or OpenOffice

In reply to this post by Jan van de Sandt

There's also the old OpenOffice Importer for Squeak 3.8 (dated 2005) at
http://map.squeak.org/package/cf85bb75-1ff8-4da1-a82e-2e53aba05818/autoversion/5

-Chris