- Pharo-dev - lists.pharo.org

[Pharo-project] zn url with passwords

by Camillo Bruni

Am I correct in the assumption that ZnURL does not support a password in the url authority? 'http://username@domain:1234/path?query_string#fragment_id' asZnUrl vs 'http://username:password@domain:1234/path?query_string#fragment_id' asZnUrl where the latter one fails. Then I just realized that 'http://username@domain:1234/path?query_string#fragment_id' asZnUrl host = 'username@domain' I would have expected it to return only 'domain'.

Jan. 29, 2013

Re: [Pharo-project] Monticello class V.S. classSide

by Damien Cassou

On Tue, Jan 29, 2013 at 11:02 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I think classSide is there for something with traits... not sure thought :P we don't have any trait in this code -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Jan. 29, 2013

Re: [Pharo-project] TxTextMorph based on new text model

by Denis Kudriashov

Hi 2013/1/29 Igor Stasenko <siguctua(a)gmail.com> > On 28 January 2013 19:37, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > This was experimental. Do not lose your time with it. Now you know that > you should continue :) > > This was to prove that "kids" could define even texteditor with simple > rules. > > > that 'script' called DSL :) > > so, yes.. you can write text editor with 10 lines of DSL code.. > + 100+ lines of code for DSL parser > + numerous hours for developers to master your DSL before they can > understand/change the code :) > > I think you all agree that smalltalk is powerfull enough to be DSL for any domain/problem. No needs for special syntax > > Stef > > > > > >> Here is the paper: http://www.vpri.org/pdf/m2010002_lobjects.pdf > >> And you can download the image with the actual active essay from > http://tinlizzie.org/lesserphic2/Text%20Field%20for%20LObject.zip > >> > >> I read paper and play with image. And I have not good impression about > this work. > >> > >> First they present text with real objects for each letter. Each letter > is actually big object with x, y, predecessor, successor and other > attributes. How much memory such model required? > >> Do you think that presenting any letter with real object (not just > character) is sufficient for modern computers? I think not. Of course such > model significantly simplified all logic around text layout stuff. But I > think it is too expensive. > >> > >> Another thing which I always not agree is introduction scripting > languages inside smalltalk. In paper all layout logic (and editing too) > programmed by "system of rules" in special scripting language (very similar > to smalltalk). If you look deeply you will see that rules call other rules > with same way methods call other methods in basic smalltalk code. So I > don't see any value of rules idea expressed with special scripts. > >> In spite of my non positive opinion I like what they do inside rules. > It is really simple and understandable code. Maybe I will try reuse > something. > >> > >> Best regards, > >> Denis > > > > > > > > > > > > > > -- > Best regards, > Igor Stasenko. > >

Jan. 29, 2013

Re: [Pharo-project] TxTextMorph based on new text model

by Igor Stasenko

On 28 January 2013 19:37, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > This was experimental. Do not lose your time with it. Now you know that you should continue :) > This was to prove that "kids" could define even texteditor with simple rules. > that 'script' called DSL :) so, yes.. you can write text editor with 10 lines of DSL code.. + 100+ lines of code for DSL parser + numerous hours for developers to master your DSL before they can understand/change the code :) > Stef > > >> Here is the paper: http://www.vpri.org/pdf/m2010002_lobjects.pdf >> And you can download the image with the actual active essay from http://tinlizzie.org/lesserphic2/Text%20Field%20for%20LObject.zip >> >> I read paper and play with image. And I have not good impression about this work. >> >> First they present text with real objects for each letter. Each letter is actually big object with x, y, predecessor, successor and other attributes. How much memory such model required? >> Do you think that presenting any letter with real object (not just character) is sufficient for modern computers? I think not. Of course such model significantly simplified all logic around text layout stuff. But I think it is too expensive. >> >> Another thing which I always not agree is introduction scripting languages inside smalltalk. In paper all layout logic (and editing too) programmed by "system of rules" in special scripting language (very similar to smalltalk). If you look deeply you will see that rules call other rules with same way methods call other methods in basic smalltalk code. So I don't see any value of rules idea expressed with special scripts. >> In spite of my non positive opinion I like what they do inside rules. It is really simple and understandable code. Maybe I will try reuse something. >> >> Best regards, >> Denis > > > > > -- Best regards, Igor Stasenko.

Jan. 29, 2013

Re: [Pharo-project] Extent a Athens surface?

by Igor Stasenko

On 28 January 2013 23:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jan 28, 2013, at 6:25 PM, Fernando Olivero wrote: > >> Hola Vanessa, >> >> i can help you if, but i don't fully understand what do you want to achieve by "extending" the surface. > > I think that creating a larger surface. > how large? is AthensCairoSurface extent: 2000@2000 not works? > Stef >> >> Saludos, >> Fernando >> >> >> On Mon, Jan 28, 2013 at 10:17 PM, Vanessa PeÃ±a Araya <van.c.pena(a)gmail.com> wrote: >> Hi, >> >> I wanted to ask if it's possible to extent an Athens surface. If it >> can't be done, because as far as I understand this can't be done in >> Cairo, is it possible to simulate it at least? Is it possible to stop >> #drawDuring: and build another surface, maybe? >> >> Thanks, >> Vanessa. >> >> > > -- Best regards, Igor Stasenko.

Jan. 29, 2013

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

by Igor Stasenko

i guess bets would be to detect that programmatically, i.e. make a function which returns struct (inside VM/plugin) and check the result, instead of relying on ifdefs.. and yes, this is a mess :) On 28 January 2013 23:58, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > 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 -- Best regards, Igor Stasenko.

Jan. 29, 2013

Re: [Pharo-project] TxText configuration

by Igor Stasenko

On 29 January 2013 08:14, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello > > > 2013/1/29 Camillo Bruni <camillobruni(a)gmail.com> >> >> 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 :) >> > Last changes is my and I continue development (slowly). But I know nothing > about ci-jobs. What I can do? > > Also Tristan Bourgois join development. And sombody (Igor) should add him to > contributors. > done -- Best regards, Igor Stasenko.

Jan. 29, 2013

Re: [Pharo-project] NativeBoostFFI out parameters passing pointers back and forth is confusing...

by Igor Stasenko

On 25 January 2013 02:13, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi: > > I don't really understand how NativeBoostFFI handles pointers. > > > I have two functions like this: > > > self call: #(int git_repository_open(git_repository * * handle, char * path)) > > and > > self call: #(int git_repository_head(git_reference * * refHandle, git_repository * repo)) > > > > They use a type mapping like this: > #('git_repository' 'NBVoid' > 'git_reference' 'NBVoid' ) > > So, nothing special going on here, just pointers to pointers, > and pointers to opaque data structures. > > Now, the call to the _open function is done with a `repoHandle := NBExternalHandle new`. > This works, and I get the result value of the c lib inside my repoHandle. > > However, if I want to use it in the _head call, I first have to convert it into a NBExternalAddress (`NBExternalAddress value: repoHandle value`). > > Took me a while to figure out that passing in the repoHandle to _head does actually do the wrong thing. > The _head function then gets the address of repoHandle instead of its value, which is wrong for my usecase. > > However, just passing in `repoHandle value` results in some strange _nil_ error. > > So, the main question is, why do I need to convert between Handle and Address? > > For the library I am trying to use, that becomes a somehow recurring pattern: > > > | repo repoPath cb branches headHandle | > repo := NBExternalHandle new. > repoPath := NBExternalAddress fromString: '/Users/smarr/tmp/filetree'. why not just pass the string? > > LG2RepositoryH uniqueInstance repository_open: repo path: repoPath. > repo := NBExternalAddress value: repo value. "<-- Why is this necessary?" > > headHandle := NBExternalHandle new. > LG2RepositoryH uniqueInstance repository_head: headHandle repo: repo. > > ^ (LG2RefsH uniqueInstance > reference_name: (NBExternalAddress value: headHandle value)) "<-- Why is this necessary?" > readString > yeah.. that double indirection is often source of confusion. but you can make a subclass of NBExternalObject , say 'GitReference' to be equal to 'git_reference *' and 'GitRepository' to 'git_repository *' like that, then in signature you need to rewrite to: self call: #(int git_repository_head(GitReference * refHandle, GitRepository repo)) this should work, because converter will push a pointer to the location where your handle value is stored (if with *) or push its value without. > > Thanks > 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 > > -- Best regards, Igor Stasenko.

Jan. 29, 2013

Re: [Pharo-project] nativeboost google groups

by Camillo Bruni

so then I want the issue tracker entries back on this mailing list. otherwise it is inconsistent... On 2013-01-29, at 10:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > well.. I more or less agree with Torsten (even if I already subscribed): component parts of Pharo should be kept together, otherwise... why not to create a group for mophic, for zinc, for filesystem, etc.? > jutst to have a nice header? do you know you have some rules that you can apply to auto-label mails? :) > > > > On Jan 29, 2013, at 9:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> subscribe and you're done, >> >> the thing you get for Free is a decent title in the message in your mail client. >> For me that saves a couple of second on each mail to check about what it is. >> >> >> On 2013-01-29, at 08:40, Torsten Bergmann <astares(a)gmx.de> wrote: >> >>> I dislike outsourcing it to a google group. NB is now part of the image >>> and the discussion should be here as well. >> >> valid point. but then again, we will anyway allways announce changes made by >> NativeBoost automatically via the update mails. >> >> Besides, the issue tracker is also no longer in the mailinglist, which is essentially >> the heart of development? How do you argue in favor of that? >> >>> Otherwise we end up with too many places nobody will be able >>> to follow or find... >> >> invalid point: >> well then the INRIA mailing lists are the worst place since they don't have >> a proper index either. the only thing that get's indexed is the mapped forum >> on http://forum.world.st/ >> >>> Please close the group since it adds more confusion. >> >> nah, my personal opinion outweighs, besides you're always free to not use it... > >

Jan. 29, 2013

Re: [Pharo-project] Monticello class V.S. classSide

by Esteban Lorenzano

I think classSide is there for something with traits... not sure thought :P On Jan 29, 2013, at 10:23 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > What is the difference between 'class' and 'classSide'? > > We believe this is one symptom of a major problem > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > <monticello-classSide.png>

Jan. 29, 2013