- Pharo-dev - lists.pharo.org

[Pharo-project] NativeBoost and NBOpenGL on Mac?

by Lawson English

I've had problems installing NativeBoost on Squeak, but it worked reasonably well installing on a Mac. However, TestRunner failed while running the callback tests. This may or may not have anything to do with trying to work with NBOpenGL, which also installs fine on Pharo (but not squeak). Basically: GLViewportMorph new "useOwnForm: true;" openInWorld fails with Error: function unavailable It fails during this: hInst := NativeBoostWin32 getVMModuleHandle. which I assume means that Mac OS X is still not supported? Any workarounds available yet? I should point out that my little kludgey youtube demo of integrating OpenGL and the squeak IDE has generated 10x as many hits per day as the next most popular video in my tutorial series on squeak. I should also point out that when I demo pier and seaside I use Pharo and explicitly point out I'm using Pharo, so the Pharo community might benefit quite a bit from me being able to use NBOpenGL on the Mac... L.

Jan. 9, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Levente Uzonyi

On Sun, 8 Jan 2012, Mariano Martinez Peck wrote: >> >> Of course, but I'd check for the class equality first, because it's faster >> (yeah, i know you turned off inlining of #class, but Cog doesn't care about >> that ;)). > > > Are you sure Cog doesn't care? I think it does. From what I can see in Cog > code the entry point to inline #class is from the bytecoodes. If you see > initializeBytecodeTableForClosureV3 > ... > #(1 199 199 genSpecialSelectorClass needsFrameNever: notMapped 0). "not > mapped because it is directly inlined (for now)" > ... > > so if you use a the normal bytecode for #class then I think #class is not > inlined in machine code. At least from my tests I noticed that. I guess you're right. Levente > > Cheers > > > >> Another thing that you should add (besides tests of course) is >> SmallInteger >> #pointsTo: which should return false. Also make sure that >> pointer tracing tools use #pointsTo:. In Squeak I found that some of them >> "reinvented" this method... >> >> >> Levente >> >> >> >>> cheers >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 9, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Levente Uzonyi

On Sun, 8 Jan 2012, Mariano Martinez Peck wrote: >> What I don't understand is why in Squeak it does work. >>> >> >> Because #pointsTo: is not used in Squeak (yet). As usual I dug deeper than >> I should have, so I'll publish a few changes soon. >> >> > Ok, you are right. Squeak #inboundPointersExcluding: is using > #instVarsInclude: rather than #pointsTo. And that solves the problem in > Pharo as well. But still, I would like to understand why we get those > method contexts with #pointsTo. Because #pointsTo: is a normal message send, it even sends other methods, so it will create contexts. > Thanks Levente for your help. If you find something let us know, I want to > learn :) I pushed my changes to the Squeak Inbox, which fully works around this issue. The changes about weak references can simply be removed if you don't like them, the rest will just work without them. Levente > > Thanks > > >> >> Levente >> >> >>> Thanks in advance Levente! >>> >>> >>> >>> >>> >>> it will create at least one new MethodContext which is not included in >>>> that list. >>>> >>>> >>>> Levente >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> Levente >>>>>> >>>>>> >>>>>> Thanks again. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Levente >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Do you mean what I understand :)? that some tools compiled methods? >>>>>>>> :) >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>> Mariano >>>>>>>>> http://marianopeck.wordpress.********com < >>>>>>>>> http://marianopeck.wordpress. >>>>>>>>> **** >>>>>>>>> com <http://marianopeck.wordpress.****com<http://marianopeck.** >>>>>>>>> wordpress.com <http://marianopeck.wordpress.com>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>> Mariano >>>>>>> http://marianopeck.wordpress.******com <http://marianopeck.wordpress. >>>>>>> **** >>>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>>> com <http://marianopeck.wordpress.com>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 9, 2012

Re: [Pharo-project] Small improvement for WriteStream >> nextPutAll:

by Henrik Sperre Johansen

On 09.01.2012 00:18, Eliot Miranda wrote: > > > On Sun, Jan 8, 2012 at 5:46 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > Hi guys. Some time ago Henry spot to us a small improvement for > WriteStream >> nextPutAll: that we are using in Fuel, but I think > it can be general. Henry comment was exactly: > > /Also: For variableBytes classes, if you rewrite: > > WriteStream > nextPutAll: aCollection > > | newEnd | > *collection class instSpec == aCollection class instSpec ifFalse:* > [^ super nextPutAll: aCollection ]. > > newEnd := position + aCollection size. > newEnd > writeLimit ifTrue: > [self growTo: newEnd + 10]. > > collection replaceFrom: position+1 to: newEnd with: aCollection > startingAt: 1. > position := newEnd. > > ^ aCollection > > You can now pass all variableByte classes (Like ByteString) > directly to a stream with a ByteArray collection, and the > replaceFrom:to:with:/ > /startingAt: primitive will work correctly, just like the file > primitive does > This means you don't need special Serializers for these either, > using f.ex. clunky nextStringPutAll: methods with manual > asByteArray conversions./ > > > So...if you agree, I can commit the patch. > > > Surely this will break special encoded strings where the encode/decode > is done in at:/at:put:. Moving the bytes isn't safe in general. > However, if the programmer knows they themselves can use > next:putAll:startingAt: or some such. I don't think your suggestion > is safe in general for WriteStream. Instead if > next:putAll:startingAt: doesn't do the job invent some new protocol > that will. In principle I agree, though the only such case I can think of in an image atm is the newly introduced: wa := WordArray new: 2. ws := wa writeStream. ws nextPutAll: 1.0 The string example in itself is rather theoretical, the "convention" is to use ByteStrings for all encodings, and let the programmer fend for himself when it comes to remembering which ByteStrings he's converted to which encoding. (A practice which, sadly, is only enabled by the collection class = aCollection class check (the one in next:putAll:startingAt:), as encoding/decoding a ByteString to a ByteString is much faster than the equivalent operation resulting in a ByteArray... ) So in practice, even the current class check does not protect against what would be the common error. Though, for a general, collection-agnostic approach which can still use primitives between compatible classes, I guess giving the nextPutAll: argument a say in what method is actually used to do a next:putAll:startingAt: would be a better approach than simply removing the check and crossing our fingers. :) Cheers, Henry

Jan. 9, 2012

Re: [Pharo-project] How can I get account on Jenkins?

by Marcus Denker

On Jan 9, 2012, at 3:41 AM, Dimitry Golubovsky wrote: > Hi, > > How can I get an account on Jenkins so I could set up build jobs for > CogDroid? Yes, let's see how we set this up. (we can do this off-list) > Such way, everybody interested could easily get access to > the latest builds. Also, people who wish to experiment with derived > versions (built on top of the core VM Java+native libraries) would be > able to do it without messing with building the VM itself, just > referencing the proper .jar and .so files. > > Thanks. > > -- > Dimitry Golubovsky > > Anywhere on the Web > -- Marcus Denker -- http://marcusdenker.de

Jan. 9, 2012

Re: [Pharo-project] CogDroid Beta Test builds

by Norbert Hartl

Am 09.01.2012 um 05:06 schrieb Dimitry Golubovsky: > This is a temporary location. Hopefully my request for Jenkins account > will be granted, and I will be able to set up automatic build jobs for > CogDroid. I think putting the build at inria is good to do. If there are reasons why this is not possible I would be happy to help out. Meaning we could build cogdroid on my jenkins server. Norbert

Jan. 9, 2012

[Pharo-project] Another lighthouse image

by Schwab,Wilhelm K

Marginal , but maybe of use: http://apod.nasa.gov/apod/ap120108.html

Jan. 9, 2012

[Pharo-project] CogDroid Beta Test builds

by Dimitry Golubovsky

Hi, As CogDroid has undergone more testing on both ARM and x86 platforms, I am pleased to announce that CogDroid is now Beta. I have made two testing builds available: http://www.golubovsky.org/userdirs/golubovsky/CogDroid-beta/CogDroid-debug.… for ARM, and http://www.golubovsky.org/userdirs/golubovsky/CogDroid-beta/CogDroid86-debu… for x86. This is a temporary location. Hopefully my request for Jenkins account will be granted, and I will be able to set up automatic build jobs for CogDroid. What has been added/changed since the latest Alpha releases: 1. The core VM Java and native code has been separated into a library. Cog-based applications may be built on top of the library. The beta versions mentioned in this message are generic builds whose code extends the base activity class adding nothing to its functionality. The beta APK have different Java package names from alpha releases. 2. A VM primitive has been added to read text from Android clipboard. In order to use this primitive, In order to use this primitive, the package http://source.squeak.org/VMMaker/Android-Base-golubovsky.21.mcz (or newer) has to be installed from the following repo: http://source.squeak.org/VMMaker/ 3. Locale support has been added. Android NDK does not provide locale support as traditional C programs would expect, so the "stock" UnixLocalePlugin does not work. The Android replacement retrieves locale information from Java runtime by making several JNI calls at the moment of plugin initialization. CogDroid does not see changes in locale if Android language/country settings are changed, until restarted. 4. Keyboard support has been improved: in both architectures Ctrl and Alt modifiers should work, however I can not test it for ARM as I do not have a tablet with keyboard. Keyboard modifiers work in x86. Thanks. -- Dimitry Golubovsky Anywhere on the Web

Jan. 9, 2012

[Pharo-project] How can I get account on Jenkins?

by Dimitry Golubovsky

Hi, How can I get an account on Jenkins so I could set up build jobs for CogDroid? Such way, everybody interested could easily get access to the latest builds. Also, people who wish to experiment with derived versions (built on top of the core VM Java+native libraries) would be able to do it without messing with building the VM itself, just referencing the proper .jar and .so files. Thanks. -- Dimitry Golubovsky Anywhere on the Web

Jan. 9, 2012

Re: [Pharo-project] loading bytecodes into the image?

by Lawson English

That happens anyway if you don't have the sources handy. However, the bytecode compiler is so simple that reverse engineering of the code is automatic. You just loose the local var names and everything is referred to as t1, t2, t3, etc. Instance variable names are hardwired into the dictionaries, I believe, so they remain available. Lawson On 1/8/12 2:03 PM, Philippe Marschall wrote: > Hi > > Ok, I'm not pretending this isn't a stupid idea, I'm just curios. > > Suppose I want to build something that would allow me to load > "compiled classes" (without sources) into the VM. How would you > approach something like this? What things need special care (bindings, > symbols, load order, â¦)? > > Cheers > Philippe > > >

Jan. 9, 2012