- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NativeBoost and unions

by StÃ©phane Ducasse

> I would recommend sthub, quick howto for moving: sthub! Let us deprecate SS for now and after we think about git. We cannot break too many eggs at the same time. > http://goran.krampe.se/2013/01/07/moving-to-smalltalkhub > > regards, GÃ¶ran

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by Igor Stasenko

On 23 January 2013 20:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 23 January 2013 17:27, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> > EstebanLM wrote >> >> Pharo 2.0 will be released with a stable, branded vm with a bunch of >> >> useful plugins and libraries (like freetype) and out-of-the-box support >> >> for NativeBoost. >> >> ... >> >> For Pharo 3.0 we are even more ambitious: we want to start replacing >> >> some >> >> important parts of the vm with plugins (like extract a "DisplayPlugin", >> >> so >> >> we can control from image side the initialization of a morphic world or >> >> something extra. And we want to replace BitBlt plugin with Athens, so >> >> that >> >> will keep us busy enough time. >> > >> > Wow, very exciting! Thank everyone for the hard work :) >> > >> > >> > EstebanLM wrote >> >> - ephemerons support. >> > >> > Is this currently available? If so, does that mean that weak >> > announcements >> > taking a block are now working properly? >> > >> no it is not integrated yet. >> After discussing with Eliot, he recommended to use last object format >> to denote ephemerons. >> Existing implementation is a bit hackish way to determine if object is >> ephemeron. >> So, before we do such change, assume they are not working yet. > > > Yes, please. This is the only thing that has kept me from integrating the > ephemeron work. We can use instSpec/format #5. The instSpec/formats are > 0: zero-fixed-sized pointers (e.g. UndefinedObject) > 1: non-zero-fixed-sized pointers (e.g. Point (x,y)) > 2: zero-fixed-size variable pointers (e.g. Array) > 3. non-zero-fixed-sized variable pointers (e.g. AdditionalMethodState > (method,selector)) > 4. arbitrary-fixed-sized variable weak pointers (e.g. WeakFinalizerItem > (list,next,executor) > 5. unused > 6. variable 32-bit non-pointers (e.g. Float) > 7. unused (but should be odd bit for length of format 6 objects in 64-bit > system) > 8. variable 8-bit non-pointers (e.g. ByteArray, String) > 9,10,11 odd bits for length of format 8 objects > 12 hybrid variable pointers, variable bytes (CompiledMethod and subclasses) > 13,14,15 odd bits for length of format 12 objects > > So 5 is the obvious one. format <= 5 are pointers, format <= 5 or >= 12 > contain pointers. 7's a really bad choice. Good. > > And I won't bore you with the extension to 64-bits and a 5 bit field. :) As a tangent.. i looking for a ways to have simpler model where we have only 2 object formats: - objects which fields are pointers - objects which contain no pointers because this is the only thing that matters for VM/GC most of the time. For other contracts, like how to treat pointers (whether they weak or ephemeron or any other kind), we could use a 'marker' object, i.e. a special object stored in first slot of questioned object. So, for example, if a first slot has reference to 'WeakKind' special object, then rest references is held weakly. By analogy, putting 'EphemeronKind' will automatically mark object as ephemeron. So, instead of using bits in header, we using extra slot. The advantage is that we're no longer constrained by the number of bits reserved for object format, and future VM can introduce any other kind, if needed, without need to touch rest. dreams, dreams.. :) -- Best regards, Igor Stasenko.

Jan. 23, 2013

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

by StÃ©phane Ducasse

On Jan 23, 2013, at 1:34 PM, Sean P. DeNigris wrote: > Thanks for tackling this urgent and complicated topic! + 1000 Stef

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by StÃ©phane Ducasse

esteban ***THANKS*** for this mail. Could you consolidate a version (including igor feedback) and post it as a blog post on the pharo web site? This is for this kind of work that we need a stronger consortium. Stef On Jan 23, 2013, at 12:40 PM, Esteban Lorenzano wrote: > Hi, > > Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins. > > Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. > But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. > What are those things? Well, a small list: > > - the adaptation of interpreter to run NativeBoost > - external semaphores enhancement to grow easily over 250. > - ephemerons support. > > in the plugins area, this year we improved some of the existing ones: > - FilePlugin, now can retrieve file permissions and knows if file is a symlink > - SerialPlugin, now works in Macs (it was never implemented) > > in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now). > > So, for Pharo 2.0 now we are working on this twi issues: > > - Stability! We need a stable VM, and as I already said it, we still have some problems there. > - Improve the build process, to make it easier. > - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :) > > Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. > > For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time. > > Cheers, > Esteban

Jan. 23, 2013

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

by DeNigris Sean

> I don't. Do you have link? 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

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by Eliot Miranda

On Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 January 2013 17:27, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote > >> Pharo 2.0 will be released with a stable, branded vm with a bunch of > >> useful plugins and libraries (like freetype) and out-of-the-box support > >> for NativeBoost. > >> ... > >> For Pharo 3.0 we are even more ambitious: we want to start replacing > some > >> important parts of the vm with plugins (like extract a "DisplayPlugin", > so > >> we can control from image side the initialization of a morphic world or > >> something extra. And we want to replace BitBlt plugin with Athens, so > that > >> will keep us busy enough time. > > > > Wow, very exciting! Thank everyone for the hard work :) > > > > > > EstebanLM wrote > >> - ephemerons support. > > > > Is this currently available? If so, does that mean that weak > announcements > > taking a block are now working properly? > > > no it is not integrated yet. > After discussing with Eliot, he recommended to use last object format > to denote ephemerons. > Existing implementation is a bit hackish way to determine if object is > ephemeron. > So, before we do such change, assume they are not working yet. > Yes, please. This is the only thing that has kept me from integrating the ephemeron work. We can use instSpec/format #5. The instSpec/formats are 0: zero-fixed-sized pointers (e.g. UndefinedObject) 1: non-zero-fixed-sized pointers (e.g. Point (x,y)) 2: zero-fixed-size variable pointers (e.g. Array) 3. non-zero-fixed-sized variable pointers (e.g. AdditionalMethodState (method,selector)) 4. arbitrary-fixed-sized variable weak pointers (e.g. WeakFinalizerItem (list,next,executor) 5. unused 6. variable 32-bit non-pointers (e.g. Float) 7. unused (but should be odd bit for length of format 6 objects in 64-bit system) 8. variable 8-bit non-pointers (e.g. ByteArray, String) 9,10,11 odd bits for length of format 8 objects 12 hybrid variable pointers, variable bytes (CompiledMethod and subclasses) 13,14,15 odd bits for length of format 12 objects So 5 is the obvious one. format <= 5 are pointers, format <= 5 or >= 12 contain pointers. 7's a really bad choice. And I won't bore you with the extension to 64-bits and a 5 bit field. > > > Also, is the Pharo branded VM on the static file server based on Jit Cog > (as > > opposed to stack, etc)? > > > which server? > > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664902.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Jan. 23, 2013

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

by Denis Kudriashov

Hello 2013/1/23 Sean P. DeNigris <sean(a)clipperadams.com> > Denis Kudriashov wrote > > I upload new version of TxText with new TxTextMorph > > Denis, thank you for taking this on! This is /so/ important. There are many > times in my experiments with reinventing the tools when I've gotten > confused > and frustrated by the way text / editors work and chosen to revert to a > more > standard way of doing things. > Same for me :) > Two things: > 1. Have you read about the experiments from VPRI? There is even an active > essay where you can see each rule being applied individually > I don't. Do you have link? > 2. Have you considered growth as text is typed in? The current "hold the > width and grow down" approach is very poor in certain applications. There > was a "growable" version that increased to a maximum length, but it was > very > hacky due to the complexity of hooking into the existing objects. My point > is, it would be great to be able to plugin different strategies here. > I really want it too. And I think it is already exists.There are two layout strateges: TxNativeTextLayoutStrategy (renamed from Simple) and TxWrapTextStrategy. First gives text autosize behaviour. TxTextMorph increases width accordingly to text line growth. Second strategy restricts visible text line by morph width. So morph can increase only height and text lines are wrapped by given restriction. It is easy to implement strategy which will wrap text by max line characters count. But now all stuff is just about text displaying. No editing, no selection and no cursor navigation yet. I will try make it real step by step. Be free to join me :) > > Thanks for tackling this urgent and complicated topic! > Sean > > And thank's Igor and Camillo. They start this project. > > > -- > View this message in context: > http://forum.world.st/TxTextMorph-based-on-new-text-model-tp4663219p4664903… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 23, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Nicolas Cellier

You don't know the power of the dark side... At least, I think there is one known uncompatibility which is ready to be solved http://code.google.com/p/cog/issues/detail?id=93 Nicolas 2013/1/23 Igor Stasenko <siguctua(a)gmail.com>: > On 23 January 2013 16:06, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> yes... in short time we need to be able to run llvm compiled vms even in older (10.5, 6) OSX versions... it cannot be so hard, after all, is just a compiler :) >> > hehe.. keep a good spirit and hope :) > > > -- > Best regards, > Igor Stasenko. >

Jan. 23, 2013

Re: [Pharo-project] NativeBoost and unions

by Ciprian Teodorov

On Wed, Jan 23, 2013 at 2:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 January 2013 19:55, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > wrote: > > Hi Igor, > > > > as usual after squeaksource restart, i lost my commit rights on the > > NativeBoost repository... > > added again. > > Thanks > > > > This time I have a small refactoring in the > > NBExternalStruct/NBExternalStructFields to enable union support. > > > > Besides that, c unions, I have implemented a first prototype, and now my > > question for you is: Should I add it in nativeboost (its rightful place > in > > my opinion), > > or should I keep it only as support code for my TalkFFI project(in > > TalkFFI-runtime)? What do you think? > > > > I think unions will be good addition to NBExternalStruct :) > > I have commited an initial version... However I am not sure about the way I compute the type size (wrt alignment). I'm doing this: sizeAlignedTo: anAlign with: aType totalSize := (totalSize alignedTo: anAlign ) max: (aType typeSize alignedTo: anAlign) but I'm not sure if the union size should be aligned, or if that alignement will be done latter one by NB... For the tests I've done it seems to work... > > > Cheers, > > Ciprian > > -- > > 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. > > -- 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. 23, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Ciprian Teodorov

The libs should be 32 bits... but it seems it is not this the issue... I have compiled clang+llvm from sources using the source distribution at: http://www.llvm.org/releases/ <http://www.llvm.org/releases/> then I have built the whole llvm distribution (using the getting started guide): *../src/configure --prefix=<path-to-install-dir> --enable-optimized --enable-jit --target=i686-apple-darwin10* * * *There is also a Getting started guide at: * http://llvm.org/releases/3.1/docs/GettingStarted.html As soon as I get some time I'll try to use osx/macport distribs maybe I can figure out what is the problem... If you guys have any ideas on how to easily distribute an image+vm+libclang i'm very interested. For now I'm thinking of doing something like CMakeVMMaker script, but I don't like that the that package seems tigtly couple with VMMaker... Cheers, ciprian On Wed, Jan 23, 2013 at 5:08 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi Mariano: > > On 23 Jan 2013, at 16:59, Mariano Martinez Peck wrote: > > > Maybe the lib needs to be 32 bits? can you check if the lib you are > trying is compiled for 32 or 64? > > Yes, it needs to be 32bit, but that's not the problem: > > smarr@minerva ~/tmp/libgit/libgit2$ file > /Developer/usr/clang-ide/lib/libclang.dylib > /Developer/usr/clang-ide/lib/libclang.dylib: Mach-O universal binary with > 2 architectures > /Developer/usr/clang-ide/lib/libclang.dylib (for architecture x86_64): > Mach-O 64-bit dynamically linked shared library x86_64 > /Developer/usr/clang-ide/lib/libclang.dylib (for architecture i386): > Mach-O dynamically linked shared library i386 > > smarr@minerva ~/tmp/libgit/libgit2$ file > /opt/local/libexec/llvm-3.1/lib/libclang.dylib > /opt/local/libexec/llvm-3.1/lib/libclang.dylib: Mach-O universal binary > with 2 architectures > /opt/local/libexec/llvm-3.1/lib/libclang.dylib (for architecture i386): > Mach-O dynamically linked shared library i386 > /opt/local/libexec/llvm-3.1/lib/libclang.dylib (for architecture x86_64): > Mach-O 64-bit dynamically linked shared library x86_64 > > Both version I have are universal binaries. > > 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 > > > -- 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. 23, 2013