- Pharo-dev - lists.pharo.org

D language

by phil＠highoctane.be

Anyone having used D to build system-level extensions for Pharo? TIA, Phil

Dec. 13, 2015

Re: [Pharo-dev] [Vm-dev] Cog Rump Xen unikernel

by Ben Coman

On Sat, Dec 12, 2015 at 4:38 AM, Holger Freyther <holger(a)freyther.de> wrote: > >> On 11 Dec 2015, at 20:09, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Ben, >> >> great to hear you're working on this! I'm watching with bated breath! BTW, you might find that Docker is easier and more general; I believe there's no Xen for ARM for example, and ARM is increasingly interesting with up coming extremely cheap 64-bit versions of Pi and PINE. Good luck!! > > @Eliot: There is Xen for ARMv8 (because ARM is interesting for multi-core servers) Indeed, ARM seems a very good fit for the Xen hypervisor. http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions_whit… Some technical info on ARM virtualization [1] 8:50 technical info starts (note, sound broken first 0:30) 11:55 nice overview of architecture virtualization support * RasPi 2 with Cortex-A7 would thus seem support Xen virtualization (but other revision not) * BeagleBoneBlack with Cortex-A8 would seem not to :( but maybe the next upgrade, the future comes around fast sometimes... * PINE with Cortex-A53 would support Xen virtualization 14:00 shows privilege model where perhaps something like the car drive-by-wire system runs in the "Secure world", and entertainment apps (e.g. Pharo/Squeak) run under the hypervisor. I'm not sure Docker provides provides this separation. 24:05 not that I understand a "2MB section" but it seems useful our VM fits within that 26:00 Handles 256 running VMs per CPU. 31:00 Timers [1] https://www.youtube.com/watch?v=uvh6Mu3j1oY > @Ben: Awesome. Will be interesting how small one can get it (with still functioning TCP/IP) StackVM = 1.4MB StackVM.unikernel = 15MB Pharo.image += 30MB so without trying gives a system ~45MB + application code Alternatively pharo-minimal.image = 6.2MB giving a system ~21MB + application code. For comparison [2] discusses typically having 1GB docker images, but they can reasonably trim it to 85MB - but how much functionality do they lose (e.g. we can retain out GUI debugger). So even though raw Go apps get down to 3.5MB, I think the rump kernel puts us in the ball park. [2] https://labs.ctl.io/optimizing-docker-images/?hvid=1OW0br cheers -ben

Dec. 12, 2015

Re: [Pharo-dev] Some GT tool for this?

by stepharo

yes Le 10/12/15 18:12, Mariano Martinez Peck a Ã©crit : > How many times have you tried to search a string as a comment of a > commit in all the history? Myself: many many times. I know we need > much better tools for that, store the history in a another way, > provide a nicer API, etc etc. And I know there were topics about that. > > However, I would deeply appreciate a very short term solution for ease > that. The model side is as simple as this: > > | packageName ancestry anscestors substring | > packageName := 'MyPackageXX'. > substring := 'whatever I want to search'. > ancestry := (MCWorkingCopy allManagers detect: [:each | each > packageName = packageName] ) ancestry. > anscestors := ancestry withBreadthFirstAncestors select: [:each | each > isKindOf: MCVersionInfo]. > anscestors select: [ :each | each message includesSubstring: substring ] > > Do you think it's worth a simple UI tool? Custom inspector of MCAncestry? > > Cheers, > > > -- > Mariano > http://marianopeck.wordpress.com

Dec. 12, 2015

[JOB] Pharo Engineer, IoT

by Marcus Denker

Engineer Position 1 Year =================== INRIA RMoD and the Pharo Consortium are looking for a full-time engineer for helping with developing Pharo. The focus of this job is "Pharo on embedded and mobile devices for the internet of things". - Embedded Pharo on ARM The currently available class of ARM devices (BeagleBone, Raspberry PI) are a very interesting platform for Pharo. The engineer should strengthen the existing efforts to get Pharo working on these platforms. - Pharo on Android Improve the support of Android devices. With Pharo6, we will migrate to a complete new design and implementation of UI, Windowing and graphics. The engineer will work on making these features available on Android devices. - Pharo itself The engineer is expected to be actively involved in helping to improve the infrastructure that the Pharo community used (CI server for continues integration, interplay with issue tracking) and to actively help with day-to-day bug fixing. We are looking for a candidate with some prior experience with Pharo - Knowledge in Dynamic Languages - Experience with mobile development is a plus - English Work in a research lab, but no paper writing, no teaching, no administration. In addition: - centrally located (one hour from Paris, 1h20 from London, 35 min from Brussels) - try a lot of good beer (our office is just 10km from the border to Belgium) - Program with Pharo all day! Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). Duration: 12 month Starting date: as soon as possible (Spring 2016) Salary: 2600-3200 euros brut / month, depending on experience Location: Lille (no remote job possible) More about Pharo: http://www.pharo.org INRIA RMOD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille/ INRIA in General: http://www.inria.fr Lille: http://en.wikipedia.org/wiki/Lille http://wikitravel.org/en/Lille Do not hesitate to contact us for more information.

Dec. 12, 2015

[JOB] Pharo Engineer, Infrastructure

by Marcus Denker

Engineer Position 1 year + 1 year ================================== INRIA RMoD and the Pharo Consortium are looking for a full-time engineer for helping with developing Pharo and the infrastructure around it. The focus of this job is the infrastructure that Pharo provides to external projects as well as the infrastructure we use to develop Pharo itself. - Infrastructure for external projects Pharo is used in many contexts: an ever growing number of frameworks are contributed by the community. Pharo already provides CI infrastructure, but what is missing is the automatic check of collections of frameworks and libraries. We want to provides validated "distributions" focussing on certain tasks, for example Pharo for Web development. - Pharo and Git Pharo has some support for using Git. The goal is to improve the support of git and other versioning systems. - Pharo itself The engineer is expected to be actively involved in helping to improve the infrastructure that the Pharo community uses (CI server for continues integration, interplay with issue tracking) and to actively help with day-to-day bug fixing. We are looking for a candidate with prior experience with Pharo and possibly some background in continuous integration: - Knowledge in Dynamic Languages - Continuous integration and deployment - English Work in a research lab, but no paper writing, no teaching, no administration. In addition: - Centrally located (one hour from Paris, 1h20 from London, 35 min from Brussels) - Try a lot of good beer (our office is just 10km from the border to Belgium) - Program with Pharo all day! Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). Duration: 12 + 12 months Starting date: Feb or March 2016 Salary: 2600-3200 euros brut / month, depending on experience Location: Lille (no remote job possible) More about Pharo: http://www.pharo.org INRIA RMOD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille/ INRIA in General: http://www.inria.fr Lille: http://en.wikipedia.org/wiki/Lille http://wikitravel.org/en/Lille Do not hesitate to contact us for more information.

Dec. 12, 2015

Re: [Pharo-dev] Cog Rump Xen unikernel

by Ben Coman

Here is the recipe for my first successful build and run through to an error... StackVM.unikernel: could not find any display driver This is done under 32-bit Debian 8 Jessie. Attached is StackRumpXenUnikernelConfig.st # Built the Rumprun Platform $ mkdir -p cogunikernel $ git clone http://repo.rumpkernel.org/rumprun $ cd rumprun $ git submodule update --init $ CC=cc ./build-rr.sh xen >> toolchain tuple: i486-rumprun-netbsdelf >> cc wrapper: i486-rumprun-netbsdelf-gcc >> installed to "/home/ben/Repos/cogunikernel/rumprun/./rumprun" # Generated Cog VM sources $ cd ../../cogunikernel $ git clone https://github.com/pharo-project/pharo-vm.git $ cd pharo-vm/image $ ./newImage.sh $ ./pharo-ui generator.image Tools > File Browser Filed in StackRumpXenUnikernelConfig.st From class comment, evaluated... StackRumpXenUnikernelConfig new generateSources; generate. # Built the StackVM and StackVM.unikernel $ bash build.sh # Tested them... $ cd ../results $ ./StackVM > bash: ./StackVM: cannot execute binary file: Exec format error Good. That was the expected result. $ rumprun xen -i StackVM.unikernel > StackVM.unikernel: could not find any display driver # Stop unikernel machine running, from another terminal... $ xl list $ xl destroy rumprun-StackVM.unikernel ================ Now I basically just poked, cut and slashed the config until it could compile and boot up the unikernel, without regard for what that may break. Making the VM *actually* work is bigger step that for now is beyond me, but I'll have a bite at it. Really my motivation in doing this after I stumbled on the rumprun tutorial, was I wanted to crack the seal on it to interest others capable :). I'd be interested if the above recipe is successful for others. Todo: * incorporate rumprun as an auto-built third party library, rather than outside, perhaps using git submodule like the rump kernel already does (if these can be nested) * determine how to deal with different rumprun toolchains (depending on which platform the target) * move the baking step from the build script to the generated CMake configuration * determine how to deal with lack of display * determine how an image file might be passed to the VM - maybe baking the VM and image into a ram disk (?) cheers -ben

Dec. 12, 2015

squeak & pharo versions of crypto and SecureSession

by Robert Withers

Folks, I cross-tested with Pharo and here are the good versions: Cryptography - squeak: Cryptography-rww.49.mcz - pharo: Cryptography-Pharo-rww.38.mcz SecureSession: - squeak & pharo: SecureSession-RobertWithers.20.mcz I hope this helps, Robert

Dec. 12, 2015

Re: [Pharo-dev] Cog Rump Xen unikernel

by Ben Coman

Whoops I notice an erroneous line in that recipe... On Sat, Dec 12, 2015 at 2:27 AM, Ben Coman <btc(a)openinworld.com> wrote: > I got curious about following up these two threads making Cog a unikernel... > So I thought I would try the "Building Rumprun Unikernels" tutorial here... > https://github.com/rumpkernel/wiki/wiki/Tutorial:-Building-Rumprun-Unikerne… > which I report here in case it was interest. The tutorial is based on > QEMU (and I think I saw a comment somewhere that Cog doesn't run so > well on QEMU and needs Bochs), so after that I adapted it from QEMU to > Xen. ... > $ cmake -G "Unix Makefiles" > -DCMAKE_TOOLCHAIN_FILE=../../rumprun/rumprun-x86_64/share/x86_64-rumprun-netbsd-toolchain.cmake > .. > $ make > $ rumprun-bake xen_pv helloer.bin helloer ERRONEOUS> $ rumprun-bake hw_generic helloer.bin helloer > $ rumprun xen -i helloer.bin cheers -ben

Dec. 12, 2015

Re: [Pharo-dev] [squeak-dev] Re: Unicode Support

by Eliot Miranda

Hi Euan, On Fri, Dec 11, 2015 at 5:45 PM, EuanM <euanmee(a)gmail.com> wrote: > Elliot, what's your take on having heterogenous collections for the > composed Unicode? > I'm not sure I'm understanding the question, but... I'm told by someone in the know that string concatenation is a big deal in certain applications, so providing tree-like representations for strings can be a win since concatenation is O(1) (allocate a new root and assign the two subtrees). It seems reasonable to have a rich library with several representations available with different trade-offs. But I'd let requirements drive design, not feature dreams. > i.e. collections with one element for each character, with some > characters being themselves a collection of characters > > (Simple character like "a" is one char, and a character which is a > collection of characters is the fully composed version of Ç (01d5), a > U (0055) with a diaeresis - Â¨ - ( 00a8 aka 0308 in combining form ) > on top to form the compatibility character Ã (ooDC) which then gets a > macron- Ì -( 0304) on top of that > > so > a #(0061) > > Ç #(01d5) = #( 00dc 0304) = #( 0055 0308 0304) > > i.e a string which alternated those two characters > > 'aÇaÇaÇaÇ' > > would be represented by something equivalent to: > > #( 0061 #( 0055 0308 0304) 0061 #( 0055 0308 0304) 0061 #( 0055 0308 > 0304) 0061 #( 0055 0308 0304) ) > > as opposed to a string of compatibility characters: > #( 0061 01d5 0061 01d5 0061 01d5 0061 01d5) > > Does alternating the type used for characters in a string have a > significant effect on speed? > I honestly don't know. You've just gone well beyond my familiarity with the issues :-). I'm just a VM guy :-). But I will say that in cases like this, real applications and the profiler are your friends. Be guided by what you need now, not by what you think you'll need further down the road. > On 11 December 2015 at 23:08, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi Todd, > > > > On Dec 11, 2015, at 12:57 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: > > > > > > On Dec 11, 2015, at 12:19, EuanM <euanmee(a)gmail.com> wrote: > > > > "If it hasn't already been said, please do not conflate Unicode and > > UTF-8. I think that would be a recipe for > > a high P.I.T.A. factor." --Richard Sargent > > > > > > Well, yes. But I think you guys are making this way too hard. > > > > A unicode character is an abstract idea - for instance the letter 'a'. > > The letter 'a' has a code point - its the number 97. How the number 97 > is > > represented in the computer is irrelevant. > > > > Now we get to transfer encodings. These are UTF8, UTF16, etc.... A > > transfer encoding specifies the binary representation of the sequence of > > code points. > > > > UTF8 is a variable length byte encoding. You read it one byte at a time, > > aggregating byte sequences to 'code points'. ByteArray would be an > > excellent choice as a superclass but it must be understood that #at: or > > #at:put refers to a byte, not a character. If you want characters, you > have > > to start at the beginning and process it sequentially, like a stream (if > > working in the ASCII domain - you can generally 'cheat' this a bit). A C > > representation would be char utf8[] > > > > UTF16 is also a variable length encoding of two byte quantities - what C > > used to call a 'short int'. You process it in two byte chunks instead of > > one byte chunks. Like UTF8, you must read it sequentially to interpret > the > > characters. #at and #at:put: would necessarily refer to byte pairs and > not > > characters. A C representation would be short utf16[]; It would also to > > 50% space inefficient for ASCII - which is normally the bulk of your > text. > > > > Realistically, you need exactly one in-memory format and stream > > readers/writers that can convert (these are typically table driven state > > machines). My choice would be UTF8 for the internal memory format and > the > > ability to read and write from UTF8 to UTF16. > > > > But I stress again...strings don't really need indexability as much as > you > > think and neither UTF8 nor UTF16 provide this property anyhow as they are > > variable length encodings. I don't see any sensible reason to have more > > than one in-memory binary format in the image. > > > > > > The only reasons are space and time. If a string only contains code > points > > in the range 0-255 there's no point in squandering 4 bytes per code point > > (same goes for 0-65535). Further, if in some application interchange is > > more important than random access it may make sense in performance > grounds > > to use utf-8 directly. > > > > Again, Smalltalk's dynamic typing makes it easy to have one's cake and > eat > > it too. > > > > My $0.02c > > > > > > _,,,^..^,,,_ (phone) > > > > > > I agree. :-) > > > > Regarding UTF-16, I just want to be able to export to, and receive > > from, Windows (and any other platforms using UTF-16 as their native > > character representation). > > > > Windows will always be able to accept UTF-16. All Windows apps *might > > well* export UTF-16. There may be other platforms which use UTF-16 as > > their native format. I'd just like to be able to cope with those > > situations. Nothing more. > > > > All this is requires is a Utf16String class that has an asUtf8String > > method (and any other required conversion methods). > > > > > > -- _,,,^..^,,,_ best, Eliot

Dec. 12, 2015

Re: [Pharo-dev] Unicode Support

by EuanM

Elliot, what's your take on having heterogenous collections for the composed Unicode? i.e. collections with one element for each character, with some characters being themselves a collection of characters (Simple character like "a" is one char, and a character which is a collection of characters is the fully composed version of Ç (01d5), a U (0055) with a diaeresis - Â¨ - ( 00a8 aka 0308 in combining form ) on top to form the compatibility character Ã (ooDC) which then gets a macron- Ì -( 0304) on top of that so a #(0061) Ç #(01d5) = #( 00dc 0304) = #( 0055 0308 0304) i.e a string which alternated those two characters 'aÇaÇaÇaÇ' would be represented by something equivalent to: #( 0061 #( 0055 0308 0304) 0061 #( 0055 0308 0304) 0061 #( 0055 0308 0304) 0061 #( 0055 0308 0304) ) as opposed to a string of compatibility characters: #( 0061 01d5 0061 01d5 0061 01d5 0061 01d5) Does alternating the type used for characters in a string have a significant effect on speed? On 11 December 2015 at 23:08, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Todd, > > On Dec 11, 2015, at 12:57 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: > > > On Dec 11, 2015, at 12:19, EuanM <euanmee(a)gmail.com> wrote: > > "If it hasn't already been said, please do not conflate Unicode and > UTF-8. I think that would be a recipe for > a high P.I.T.A. factor." --Richard Sargent > > > Well, yes. But I think you guys are making this way too hard. > > A unicode character is an abstract idea - for instance the letter 'a'. > The letter 'a' has a code point - its the number 97. How the number 97 is > represented in the computer is irrelevant. > > Now we get to transfer encodings. These are UTF8, UTF16, etc.... A > transfer encoding specifies the binary representation of the sequence of > code points. > > UTF8 is a variable length byte encoding. You read it one byte at a time, > aggregating byte sequences to 'code points'. ByteArray would be an > excellent choice as a superclass but it must be understood that #at: or > #at:put refers to a byte, not a character. If you want characters, you have > to start at the beginning and process it sequentially, like a stream (if > working in the ASCII domain - you can generally 'cheat' this a bit). A C > representation would be char utf8[] > > UTF16 is also a variable length encoding of two byte quantities - what C > used to call a 'short int'. You process it in two byte chunks instead of > one byte chunks. Like UTF8, you must read it sequentially to interpret the > characters. #at and #at:put: would necessarily refer to byte pairs and not > characters. A C representation would be short utf16[]; It would also to > 50% space inefficient for ASCII - which is normally the bulk of your text. > > Realistically, you need exactly one in-memory format and stream > readers/writers that can convert (these are typically table driven state > machines). My choice would be UTF8 for the internal memory format and the > ability to read and write from UTF8 to UTF16. > > But I stress again...strings don't really need indexability as much as you > think and neither UTF8 nor UTF16 provide this property anyhow as they are > variable length encodings. I don't see any sensible reason to have more > than one in-memory binary format in the image. > > > The only reasons are space and time. If a string only contains code points > in the range 0-255 there's no point in squandering 4 bytes per code point > (same goes for 0-65535). Further, if in some application interchange is > more important than random access it may make sense in performance grounds > to use utf-8 directly. > > Again, Smalltalk's dynamic typing makes it easy to have one's cake and eat > it too. > > My $0.02c > > > _,,,^..^,,,_ (phone) > > > I agree. :-) > > Regarding UTF-16, I just want to be able to export to, and receive > from, Windows (and any other platforms using UTF-16 as their native > character representation). > > Windows will always be able to accept UTF-16. All Windows apps *might > well* export UTF-16. There may be other platforms which use UTF-16 as > their native format. I'd just like to be able to cope with those > situations. Nothing more. > > All this is requires is a Utf16String class that has an asUtf8String > method (and any other required conversion methods). > >

Dec. 12, 2015