- Pharo-dev - lists.pharo.org

Re: [Pharo-project] nativeboost google groups

by StÃ©phane Ducasse

but this is always good to know the limit of key infrastructure of pharo. So now we will not know it, only if we register to the google group. Stef > it's mostly offtopic low-level stuff which has nothing to do with Pharo per se. > > hence separate mailing list, plus it's much easier to separate discussions ;). > > > On 2013-01-28, at 23:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> why? >> because this is cool to see that there is activity around NB >> >> Stef >> >>> I thought it might be a good idea to outsource the nativeboost discussions from the main mailinglist. >>> So I started a new google groups: >>> >>> https://groups.google.com/forum/?fromgroups#!forum/nativeboost >>> nativeboost(a)googlegroups.com >>> >>> cami >> >> > >

Jan. 28, 2013

[Pharo-project] TxText configuration

by Camillo Bruni

Who's in charge of the development of TxText right now? It would like the maintainers on the ci-job description: https://ci.inria.fr/rmod/job/TxText/ thanks :)

Jan. 28, 2013

Re: [Pharo-project] nativeboost google groups

by Camillo Bruni

it's mostly offtopic low-level stuff which has nothing to do with Pharo per se. hence separate mailing list, plus it's much easier to separate discussions ;). On 2013-01-28, at 23:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > why? > because this is cool to see that there is activity around NB > > Stef > >> I thought it might be a good idea to outsource the nativeboost discussions from the main mailinglist. >> So I started a new google groups: >> >> https://groups.google.com/forum/?fromgroups#!forum/nativeboost >> nativeboost(a)googlegroups.com >> >> cami > >

Jan. 28, 2013

Re: [Pharo-project] NativeBoost linux 8 byte structures

by Ciprian Teodorov

Thank you guys, you got me started... I've submitted a quick fix... however we'll need to write some linux tests... Cheers, On Mon, Jan 28, 2013 at 11:20 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > See also this thread > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-May/064140.html, > and this link http://www.shell-storm.org/papers/files/657.pdf to give > you an idea of how messy every-one-else-but-your-own low level code > can be... > > Nicolas > > 2013/1/28 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Sun, Jan 27, 2013 at 2:26 PM, Ciprian Teodorov > > <ciprian.teodorov(a)gmail.com> wrote: > >> > >> Hi Guys, > >> > >> Today I wanted to test my TalkFFI project on linux, and I run into some > NB > >> issue. > >> It seems that the VM crashes when trying to invoke a function returning > a > >> 8 byte structure. > >> I have tried with 4 bytes structure and I get some bogus data but no > crash > >> with 12 bytes structure it seems to work... > > > > > > I suspect this is a win32/linux difference that NB doesn't handle yet. > On > > win32 power-of-two structures <= 8 bytes in length are returned in > > registers. On linux they're always returned through memory. Here are > the > > relevant defs from the ThreadedIA32FFIPlugin > > > > > > #if defined(_X86_) || defined(i386) || defined(__i386) || > defined(__i386__) > > /* Both Mac OS X x86 and Win32 x86 return structs of a power of two in > size > > * less than or equal to eight bytes in length in registers. Linux never > > does so. > > */ > > # if __linux__ > > # define WIN32_X86_STRUCT_RETURN 0 > > # else > > # define WIN32_X86_STRUCT_RETURN 1 > > # endif > > > > #define returnStructInRegisters(sz) (WIN32_X86_STRUCT_RETURN && (sz) <= > 8 && > > !((sz)&((sz)-1))) > > > > > > HTH > > > >> Attached to this mail you will find a simple test case. > >> > >> the c file I have compiled with: > >> > >> gcc -g -fPIC -Wall -c -m32 strreturn.c > >> gcc -shared -g -Wl,-soname,libret.so.1 -o libret.so -m32 strreturn.o -lc > >> > >> Cheers, > >> -- > >> Dr. Ciprian TEODOROV > >> IngÃ©nieur DÃ©veloppement CAO > >> > >> tÃ©l : 06 08 54 73 48 > >> mail : ciprian.teodorov(a)gmail.com > >> www.teodorov.ro > > > > > > > > > > -- > > best, > > Eliot > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 28, 2013

Re: [Pharo-project] nativeboost google groups

by StÃ©phane Ducasse

why? because this is cool to see that there is activity around NB Stef > I thought it might be a good idea to outsource the nativeboost discussions from the main mailinglist. > So I started a new google groups: > > https://groups.google.com/forum/?fromgroups#!forum/nativeboost > nativeboost(a)googlegroups.com > > cami

Jan. 28, 2013

[Pharo-project] nativeboost google groups

by Camillo Bruni

I thought it might be a good idea to outsource the nativeboost discussions from the main mailinglist. So I started a new google groups: https://groups.google.com/forum/?fromgroups#!forum/nativeboost nativeboost(a)googlegroups.com cami

Jan. 28, 2013

Re: [Pharo-project] [ann] glamorous debugger (alpha)

by Andrei Vasile Chis

First load the model: Gofer new url: 'http://ss3.gemstone.com/ss/DebuggerModel'; package: 'ConfigurationOfDebuggerModel'; load. (Smalltalk at: #ConfigurationOfDebuggerModel) loadDefault. Second from the spec repo from ss3 (http://ss3.gemstone.com/ss/Spec) merge the commit Spec-Widgets-AndreiChis.71 into the image and then load the package Spec-Debugger and you are done. Now the previous examples should work. Also in the pre-debug you may choose to open the spec debugger. Right now the spec interface hasn't got that many features, just the basic actions. ( also in order to see the current selection in the code pane you need to move the mouse over the code pane). The one in glamour is more advance, but for now glamour does not load happily into pharo 2.0 Andrei On Mon, Jan 28, 2013 at 11:12 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Yes I do :) > So cool. > > Stef > > On Jan 28, 2013, at 6:15 PM, Andrei Vasile Chis wrote: > > > Hi all, > > > > As I'm playing with the debugger I thought I'll share with you a nice > > feature the current model supports: scripting the actions > > > > In the current version the following code is a rather complicated > > way of opening a debugger for the code '#(1 2 3 4 5) do: [:each | each > asString ]' > > > > [ |process| > > process := Processor activeProcess. > > UIManager default defer: [ |debugger session| > > session := SpecDebugger spanNewSessionForProcess: process. > "create the model" > > session errorWasInUIProcess: false. > > > > debugger := SpecDebugger debugSession: session. "open > the debugger"]. > > process suspend. > > > > "The previous lines open a debugger for this code" > > #(1 2 3 4 5) do: [:each | each asString ] > > ] fork. > > > > However, the nice thing about the code above is that as the model is > completely > > separated from the ui, the model can be used to script some actions > (stepInto, stepThrough, etc) > > before or after opening the debugger. So in the code bellow using one of > the two > > commented blocks of code, one execute some actions before or after > opening the debugger. > > > > [ |process| > > process := Processor activeProcess. > > UIManager default defer: [ |debugger session| > > session := SpecDebugger spanNewSessionForProcess: process. > "create the model" > > session errorWasInUIProcess: false. > > > > "session > > stepInto; > > stepThrough; > > stepThrough; > > stepThrough; > > stepThrough; > > stepOver; > > stepInto." > > > > debugger := SpecDebugger debugSession: session. "open > the debugger" > > > > "debugger session > > confirm: 'Step Into'; > > stepInto; > > confirm: '4 * Step Through'; > > stepThrough; > > stepThrough; > > stepThrough; > > stepThrough; > > confirm: 'Step Over'; > > stepOver; > > confirm: 'Step Into'; > > stepInto." ]. > > process suspend. > > > > "The previous lines open a debugger for this code" > > #(1 2 3 4 5) do: [:each | each asString ] > > ] fork. > > > > Also the same model can be used with multiple ui's or the same ui can be > reused with different models. > > Right now this works in Pharo 2.0, but there isn't a configuration for > loading it; if someone really wants to > > try it I can provide instructions of how to load the code. > > > > Cheers, > > Andrei > > >

Jan. 28, 2013

Re: [Pharo-project] NativeBoost linux 8 byte structures

by Nicolas Cellier

See also this thread http://lists.gforge.inria.fr/pipermail/pharo-project/2012-May/064140.html, and this link http://www.shell-storm.org/papers/files/657.pdf to give you an idea of how messy every-one-else-but-your-own low level code can be... Nicolas 2013/1/28 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Sun, Jan 27, 2013 at 2:26 PM, Ciprian Teodorov > <ciprian.teodorov(a)gmail.com> wrote: >> >> Hi Guys, >> >> Today I wanted to test my TalkFFI project on linux, and I run into some NB >> issue. >> It seems that the VM crashes when trying to invoke a function returning a >> 8 byte structure. >> I have tried with 4 bytes structure and I get some bogus data but no crash >> with 12 bytes structure it seems to work... > > > I suspect this is a win32/linux difference that NB doesn't handle yet. On > win32 power-of-two structures <= 8 bytes in length are returned in > registers. On linux they're always returned through memory. Here are the > relevant defs from the ThreadedIA32FFIPlugin > > > #if defined(_X86_) || defined(i386) || defined(__i386) || defined(__i386__) > /* Both Mac OS X x86 and Win32 x86 return structs of a power of two in size > * less than or equal to eight bytes in length in registers. Linux never > does so. > */ > # if __linux__ > # define WIN32_X86_STRUCT_RETURN 0 > # else > # define WIN32_X86_STRUCT_RETURN 1 > # endif > > #define returnStructInRegisters(sz) (WIN32_X86_STRUCT_RETURN && (sz) <= 8 && > !((sz)&((sz)-1))) > > > HTH > >> Attached to this mail you will find a simple test case. >> >> the c file I have compiled with: >> >> gcc -g -fPIC -Wall -c -m32 strreturn.c >> gcc -shared -g -Wl,-soname,libret.so.1 -o libret.so -m32 strreturn.o -lc >> >> Cheers, >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro > > > > > -- > best, > Eliot

Jan. 28, 2013

Re: [Pharo-project] Drawing text in Athens

by StÃ©phane Ducasse

She meant string rendering. String rendering is working. The problem was that some examples are broken :( > Hi Vanessa, > > AFAIK, text rendering with Athens is still not finished, but not sure about that :) > (yeah, not of much help :P) > > Esteban > > On Jan 28, 2013, at 8:45 PM, Vanessa PeÃ±a Araya <van.c.pena(a)gmail.com> wrote: > >> Hi, >> >> I'm trying to render a Roassal view using Athens. I finally was able to setup everything and some Athens examples works. However when I try to render text the image crash. I had free type selected and tried in Pharo 1.4 and 2.0 >> >> Any idea why this can be? >> >> Thanks, >> Vanessa. >> > >

Jan. 28, 2013

Re: [Pharo-project] [ann] glamorous debugger (alpha)

by StÃ©phane Ducasse

Yes I do :) So cool. Stef On Jan 28, 2013, at 6:15 PM, Andrei Vasile Chis wrote: > Hi all, > > As I'm playing with the debugger I thought I'll share with you a nice > feature the current model supports: scripting the actions > > In the current version the following code is a rather complicated > way of opening a debugger for the code '#(1 2 3 4 5) do: [:each | each asString ]' > > [ |process| > process := Processor activeProcess. > UIManager default defer: [ |debugger session| > session := SpecDebugger spanNewSessionForProcess: process. "create the model" > session errorWasInUIProcess: false. > > debugger := SpecDebugger debugSession: session. "open the debugger"]. > process suspend. > > "The previous lines open a debugger for this code" > #(1 2 3 4 5) do: [:each | each asString ] > ] fork. > > However, the nice thing about the code above is that as the model is completely > separated from the ui, the model can be used to script some actions (stepInto, stepThrough, etc) > before or after opening the debugger. So in the code bellow using one of the two > commented blocks of code, one execute some actions before or after opening the debugger. > > [ |process| > process := Processor activeProcess. > UIManager default defer: [ |debugger session| > session := SpecDebugger spanNewSessionForProcess: process. "create the model" > session errorWasInUIProcess: false. > > "session > stepInto; > stepThrough; > stepThrough; > stepThrough; > stepThrough; > stepOver; > stepInto." > > debugger := SpecDebugger debugSession: session. "open the debugger" > > "debugger session > confirm: 'Step Into'; > stepInto; > confirm: '4 * Step Through'; > stepThrough; > stepThrough; > stepThrough; > stepThrough; > confirm: 'Step Over'; > stepOver; > confirm: 'Step Into'; > stepInto." ]. > process suspend. > > "The previous lines open a debugger for this code" > #(1 2 3 4 5) do: [:each | each asString ] > ] fork. > > Also the same model can be used with multiple ui's or the same ui can be reused with different models. > Right now this works in Pharo 2.0, but there isn't a configuration for loading it; if someone really wants to > try it I can provide instructions of how to load the code. > > Cheers, > Andrei

Jan. 28, 2013