- Pharo-dev - lists.pharo.org

Pharo is cool

by Norbert Hartl

The best smalltalk/pharo moments you get if you try things you want to have just in order to see they are already there. Today FileBrowser. I switched one of my servers to dump to stack with fuel to disk if an exception occurs. Today I copied the files from the server to my local machine and opened a workspace starting to write an expression to open them. Then I thought it would be cool if I could use the file browser for it. So I opened it and navigated to the directory with the fuel filesâ¦et voilÃ â¦as soon as I clicked on a fuel file a button âmaterializeâ appeared which showed the stack from the server right away. Just brilliant! Well done! Norbert

Feb. 26, 2014

Re: [Pharo-dev] easier start with Phobos

by Pavel Krivanek

Hi Alexandre, there are some bundles based on Pharo 2.0 on the CI: https://ci.inria.fr/pharo-contribution/view/Phobos/. They work slightly differently because Pharo server is started by the JavaScript client internally. It's not so easy then to modify Smalltalk sources mainly on Mac. I'm not sure that it makes sense to waste space on our servers to provide almost the same thing when people can play with it using few more clicks. However maybe I will add them. Cheers, -- Pavel 2014-02-26 2:26 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > I do not have much time to play with this, but can you give a one-click > ready-to-use example? > > Alexandre > > > On Feb 25, 2014, at 8:07 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > If you want do develop applications in Pharo with native user interface, > you can use Phobos framework based on Mozilla XULRunner client. However to > start with it required to download a bundle for your platform and make some > modifications in configuration files. > > > > To make the entry point easier I created a configuration of Phobos that > you can download directly in the Configuration Browser in Pharo 3.0. During > the download it will ask you whether you want to run PhobosDemo > application. Answer yes and it will download required files for you > including XULRunner for your platform into the working directory (on Linux > it expects xulrunner is already preinstalled). Mainly on Windows make sure > that Pharo is enabled on your firewall because it needs to start a server > (default port is 46528). Then it should show a window with rich demo of > Phobos capabilities. You can play with sources of the PhobosDemo package. > > > > To start to write your own application firstly stop the demo: > > > > PhobosDemo allInstancesDo: #stop. > > > > Then make own subclass of PhobosApplication, create own subclass of > PhobosComponent and specify it in your application class as mainClass. Star > the server. > > > > app := MyPhobosApp new. > > app start. > > > > ..and restart the client. It is useful to run the client with the > argument -jsconsole to show errors on the JavaScript side. On MacOS you > need to modify the file PhobosDemo.app/Contents/MacOS/start.sh > > > > Please let me know if something will went wrong. > > > > Cheers, > > -- Pavel > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Feb. 26, 2014

Re: [Pharo-dev] iPad version does not work ?

by jannik laval

Thank you Esteban, It works. I failed probably because I did not remove the app in the simulator. Thank you again. Jannik 2014-02-25 13:26 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > btw what can be happening is that xcode fails to build freetype2. > the way to workaround this problem is: > > first, build a makefile version of the app: > > sh build.sh > > then, re-prepare for xcode: > > rm CMakeCache.txt > cmake -G Xcode . > > > (that will build freetype2 first, and when xcode tries to get it, it will > be already there, so it will ski the build part, who often and mysteriously > fails) > > Esteban > > > On 25 Feb 2014, at 13:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > that works for me. > what is the problem you are having? > > > On 25 Feb 2014, at 12:10, jannik laval <jannik.laval(a)gmail.com> wrote: > > It seems to not work :( > Here is the process I follow: > > === > git clone https://github.com/pharo-project/pharo-vm.git > cd pharo-vm/image/ > ./newImage.sh ==> it load a pharo20 > > ./pharo generator.image eval --save PharoIPhoneBuilder buildIPhoneSimulator > > cd ../iosbuild/resources/ > > ./generate.sh ==> it is a pharo1.4 image. > > sudo ../scripts/extract-commit-info.sh > sudo cmake -G Xcode . > > open iPharoSimulator.xcodeproj/ > > In the list "ALL_BUILD", go to edit scheme, and change the Executable > field to the iPharo. > Select your iOS version and compile it. > === > > Jannik > > > 2014-02-25 9:23 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 25 Feb 2014, at 08:04, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >> >> >> On 25 Feb 2014, at 01:31, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> it *should* be working now. >> >> cheers >> Esteban (who needs to write more documentation, but he does what he can >> :) ) >> >> >> No need lentghly sentences just some nice bulleted lists of actions >> and we can do something with that. >> >> >> yes, I will... but as I always say: time is a tyrant. And writing >> documentation is boring :) >> Anyway most of the process is already covered with current documentation, >> I just need to add a few points. >> >> (no one reads documentation either, is a bit annoying... every time is like >> starting from scratch... But don't take me into appoint, I'm having a cynical >> morning :P) >> >> Esteban >> >> >> >> >> >> On 24 Feb 2014, at 08:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> not yet... so far I restored the build capability, not the image event >> handling :( >> (nevertheless, I'm on it :) ) >> >> Esteban >> >> On 24 Feb 2014, at 08:00, jannik laval <jannik.laval(a)gmail.com> wrote: >> >> Hi Esteban, >> >> Did you already try ? >> I saw a message on the VM repo related to iOS, not sure it is for my >> problem. >> >> Cheers, >> Jannik >> >> >> 2014-01-29 17:32 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> oks... I will take a look... as soon as I can :S >>> >>> (damn... I need to learn how to do a mitosis...) >>> >>> On 29 Jan 2014, at 17:28, jannik laval <jannik.laval(a)gmail.com> wrote: >>> >>> I confirm that it does not work: the simulator compile (but not the >>> non-simulator). >>> Then the image cannot be open: I have a white screen. >>> Here is my process: >>> >>> === >>> 1) git clone https://github.com/pharo-project/pharo-vm.git >>> 2) in ./image dir prepare a VMMaker image (including download of a pharo >>> 2.0): >>> ./newImage.sh >>> >>> 3)open the generated.image and execute: >>> === >>> PharoIPhoneBuilder buildIPhone. >>> -- or -- >>> PharoIPhoneBuilder buildIPhoneSimulator. >>> >>> 4) Generate your iPhone image in iosbuild/resources/ >>> ./generate.sh >>> >>> 5) In dir ./build: >>> sh build.sh >>> === >>> >>> Cheers, >>> Jannik >>> >>> >>> >>> 2014-01-29 Esteban Lorenzano <estebanlm(a)gmail.com> >>> >>>> and btw... >>>> >>>> iosbuild/resource$ ./generate.sh >>>> >>>> should generate a 1.4 image that *should* work in ipad (no idea if that >>>> will be the case, its been more than 6months since I do not test it and vm >>>> changed since then). >>>> >>>> Esteban >>>> >>>> >>>> On 29 Jan 2014, at 10:23, Esteban Lorenzano <estebanlm(a)gmail.com> >>>> wrote: >>>> >>>> PharoIPhoneBuilder buildIPhone. >>>> >>>> it should generate all sources and a "build.sh" >>>> >>>> then >>>> >>>> build$ sh build.sh >>>> >>>> will generate an xcode project. >>>> >>>> and let me remember... mmm... yeah, that was all :) >>>> >>>> >>>> >>>> On 29 Jan 2014, at 08:10, jannik laval <jannik.laval(a)gmail.com> wrote: >>>> >>>> Hi Esteban, >>>> >>>> Hum, this means that my instructions are outdated. >>>> Where are the right instructions ? The ones on Github do not mention >>>> IOS. >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>> 2014-01-29 Esteban Lorenzano <estebanlm(a)gmail.com> >>>> >>>>> >>>>> On 29 Jan 2014, at 00:18, Eliot Miranda <eliot.miranda(a)gmail.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jan 28, 2014 at 2:46 PM, Esteban Lorenzano < >>>>> estebanlm(a)gmail.com> wrote: >>>>> >>>>>> because you are not following the instructions ;) >>>>>> >>>>>> basically... you can generate them by: >>>>>> >>>>>> build$ ../scripts/extract-commit-info.sh >>>>>> >>>>> >>>>> I asked for this info last week ;-). Thanks! >>>>> >>>>> >>>>> hey! I answered you! :P >>>>> >>>>> >>>>> >>>>> But this is alarming: >>>>> >>>>> McStalker.pharovm$ ./scripts/extract-commit-info.sh >>>>> readlink: ./scripts/extract-commit-info.sh Invalid argument >>>>> >>>>> I suggest changing >>>>> SCRIPT_DIR=`readlink "$0"` || SCRIPT_DIR="$0"; >>>>> to read >>>>> SCRIPT_DIR=`readlink "$0" >/dev/null` || SCRIPT_DIR="$0"; >>>>> >>>>> >>>>> Esteban >>>>>> >>>>>> On 28 Jan 2014, at 23:15, jannik.laval <jannik.laval(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> Thank you, I am trying the latest one. >>>>>> >>>>>> When compiling for IOS, I have an error in sqSCCSVersion.h >>>>>> >>>>>> #include "vmVersionInfo.h" // defines REVISION_STRING >>>>>> the file is not found. >>>>>> >>>>>> Anyone knows where is this file ? >>>>>> >>>>>> Cheers, >>>>>> Jannik >>>>>> >>>>>> On Jan 28, 2014, at 8:58 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >>>>>> >>>>>> jannik the latest vm is not on gitoruous anymore but git >>>>>> >>>>>> >>>>>> On 27 Jan 2014, at 22:03, jannik laval <jannik.laval(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hum, have I the correct repository ? >>>>>> I used this one: https://git.gitorious.org/cogvm/cog-osx.git >>>>>> >>>>>> But, I just saw that this one exists: >>>>>> https://github.com/pharo-project/pharo-vm >>>>>> I should use it no? >>>>>> >>>>>> Jannik >>>>>> >>>>>> >>>>>> 2014-01-27 Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>> >>>>>>> 1.4 and 2.0 worked out of the box... and after my latest integration, >>>>>>> 3.0 should work too. >>>>>>> I will take a look as soon as I have half and hour to spare. >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> >>>>>>> On 27 Jan 2014, at 14:27, jannik laval <jannik.laval(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hi list, >>>>>>> >>>>>>> Does anyone try to load Pharoon iPad ? >>>>>>> In the past, the version 1.4 worked with XCode 4.4. >>>>>>> >>>>>>> I just tried to recompile it with the new XCode (5.0.2). >>>>>>> The VM seems to work, but the pharo 1.4 image freezes. >>>>>>> >>>>>>> Any idea ? >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ~~Jannik Laval~~ >>>>>>> Ãcole des Mines de Douai >>>>>>> Enseignant-chercheur >>>>>>> http://www.jannik-laval.eu >>>>>>> http://car.mines-douai.fr/ >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> ~~Jannik Laval~~ >>>>>> Ãcole des Mines de Douai >>>>>> Enseignant-chercheur >>>>>> http://www.jannik-laval.eu >>>>>> http://car.mines-douai.fr/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> best, >>>>> Eliot >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> ~~Jannik Laval~~ >>>> Ãcole des Mines de Douai >>>> Enseignant-chercheur >>>> http://www.jannik-laval.eu >>>> http://car.mines-douai.fr/ >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> ~~Jannik Laval~~ >>> Ãcole des Mines de Douai >>> Enseignant-chercheur >>> http://www.jannik-laval.eu >>> http://car.mines-douai.fr/ >>> >>> >>> >> >> >> -- >> >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://car.mines-douai.fr/ >> >> >> >> >> >> > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://car.mines-douai.fr/ > > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

Feb. 26, 2014

Re: [Pharo-dev] Pharo contribution CI: Email on failed build

by Christophe Demarey

Hello, Le 25 fÃ©vr. 2014 Ã 16:53, Damien Cassou a Ã©crit : > On Tue, Feb 25, 2014 at 4:42 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Is it possible to receive an email when the build of the project I registered turns to unstable? > > yes, just add a post build action "Email notification" and put your > email address there. I would suggest to use the "Editable email notification". It is a Jenkins plugin (already available on pharo-contribution) that is really better. With this one, you can customize recipients, the mail content, attach the build log, etc. The most important feature to me is that you can define specific triggers like: - on regression send a mail to RecipientsDevelopersRequestorCulprits - on failure, ... - etc. It is usable without configuring anything but the recipient list. The default template is already configured. More details here: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin Christophe.

Feb. 26, 2014

In Praise of Small Commits | Dr Dobb's

by Sven Van Caekenberghe

http://www.drdobbs.com/architecture-and-design/in-praise-of-small-commits/2… << With smaller commits, teams accelerate code reviews and builds, while shrinking the delay between committing and feedback. That's a lot of payback for a simple practice. >> >From an integration standpoint, I love small and clean Slices. Sven

Feb. 26, 2014

Re: [Pharo-dev] iPad version does not work ?[SEC=UNCLASSIFIED]

by phil＠highoctane.be

Ah, yes, I saw that in the README but haven't yet been able to get the Sim to work. Have you? Phil On Wed, Feb 26, 2014 at 9:01 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Yes it is. Take a look at the readme :) > > On 26 Feb 2014, at 08:28, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > > You can make it work following the procedure: > http://www.youtube.com/watch?v=7MNsUiCc5FQ&list=UUul18dYQnhOVMfYFg6YSK4A > > I don't know if you will have to mess with the Xcode project afterwards at > this point but I remember I had to do weird things to get Cmake to work, > due to some bugs in it. > > So, make sure you have the right version. > > What I didn't got working was the simulator version. Someone having it > working at this point? > > Phil > >

Feb. 26, 2014

Re: [Pharo-dev] iPad version does not work ?[SEC=UNCLASSIFIED]

by Esteban Lorenzano

Yes it is. Take a look at the readme :) > On 26 Feb 2014, at 08:28, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > > You can make it work following the procedure: http://www.youtube.com/watch?v=7MNsUiCc5FQ&list=UUul18dYQnhOVMfYFg6YSK4A > > I don't know if you will have to mess with the Xcode project afterwards at this point but I remember I had to do weird things to get Cmake to work, due to some bugs in it. > > So, make sure you have the right version. > > What I didn't got working was the simulator version. Someone having it working at this point? > > Phil

Feb. 26, 2014

Re: [Pharo-dev] hashMultiply

by phil＠highoctane.be

Andres, Thanks for the insights. hash quality is indeed an key factor. At least, my mind is somewhat grasping this hashing field a bit better. I'll have a look at the tools, I haven't used them yet. And a shot at the ASM version with NativeBoost in Pharo. For what occurs in modern CPUs, well, no. Surprising to see that a mul would be faster than a shr or shl. How comes? I used to be ok with these things when I was writing demoscene code a loong time ago but I'd need an extremely serious refresh. As a side note, there is a huge uptake in the BigData/mapreduce/hadoop environment where Smalltalk is sorely absent. Scala seems to fill the void on the JVM. There hashing is quite key, to remap all of the mapping phase results to the reduce nodes. I am surprised to see that Smalltalk vendors haven't jumped in that space. Phil On Wed, Feb 26, 2014 at 2:04 AM, Andres Valloud < avalloud(a)smalltalk.comcastbiz.net> wrote: > Hello... > > On 2/25/14 1:17 , phil(a)highoctane.be wrote: > >> I am currently reading through the Hashing in Smalltalk book >> (http://www.lulu.com/shop/andres-valloud/hashing-in- >> smalltalk-theory-and-practice/paperback/product-3788892.html) >> and, my head hurting notwithstanding, there are indeed a ton of gems in >> this system. As he mentions, doing the exercises brings a lot of extra :-) >> > > :) thank you. > > When going to 64-bit, and with the new ObjectMemory scheme, I guess a >> couple of identity hashing functions will come under scrutiny. >> >> e.g. >> >> SmallInteger>>hashMultiply >> | low | >> >> low := self bitAnd: 16383. >> ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) >> bitAnd: 16383) * 16384)) >> bitAnd: 16r0FFFFFFF >> >> >> which will need some more bits. >> > > IMO it's not clear that SmallInteger>>identityHash should be implemented > that way. Finding a permutation of the small integers that also behaves > like a good quality hash function and evaluates quickly (in significantly > less time and complexity than, say, Bob Jenkins' lookup3) would be a really > interesting research project. I don't know if it's possible. If no such > thing exists, then getting at least some rough idea of what's the minimum > necessary complexity for such hash functions would be valuable. > > Looking at hashMultiply as a non-identity hash function, one would start > having problems when significantly more than 2^28 objects are stored in a > single hashed collection. 2^28 objects with e.g. 12 bytes per header and a > minimum of one instance variable (so the hash value isn't a > instance-constant) stored in a hashed collection requires more than 4gb, so > that is clearly a 64 bit image problem. In 64 bits, 2^28 objects with e.g. > 16 bytes per header and a minimum of one instance variable each is already > 6gb, and a minimum of 8gb with the hashed collection itself. > > Because of these figures, I'd think improving the implementation of hashed > collections takes priority over adding more non-identity hash function bits > (as long as the existing hash values are of good quality). > > Did you look at the Hash Analysis Tool I wrote? It's in the Cincom public > Store repository. It comes in two bundles: Hash Analysis Tool, and Hash > Analysis Tool - Extensions. With everything loaded, the tool comes with > 300+ hash functions and 100+ data sets out of the box. The code is MIT. > > I had a look at how it was done in VisualWorks; >> > > The implementation of hashMultiply, yes. Note however that > SmallInteger>>hash is ^self. > > hashMultiply >> "Multiply the receiver by 16r0019660D mod 2^28 >> without using large integer arithmetic for speed. >> The constant is a generator of the multiplicative >> subgroup of Z_2^30, see Knuth's TAOCP vol 2." >> <primitive: 1747> >> | low14Bits | >> low14Bits := self bitAnd: 16r3FFF. >> ^16384 >> * (16r260D * (self bitShift: -14) + (16r0065 * low14Bits) bitAnd: 16r3FFF) >> + (16r260D * low14Bits) bitAnd: 16rFFFFFFF >> >> The hashing book version has: >> >> multiplication >> "Computes self times 1664525 mod 2^38 while avoiding overflow into a >> large integer by making the multiplication into two 14 bits chunks. Do >> not use any division or modulo operation." >> | lowBits highBits| >> >> lowBits := self bitAnd: 16r3FFF. >> highBits := self bitShift: -14. >> ^(lowBits * 16r260D) >> + (((lowBits * 16r0065) bitAnd: 16r3FFF) bitShift: 14) >> + (((highBits * 16r260D) bitAnd: 16r3FFF) bitShift: 14) >> bitAnd: 16rFFFFFFF >> >> So, 16384 * is the same as bitShift: 14 and it looks like done once, >> which may be better. >> > > It should be a primitive (or otherwise optimized somehow). At some point > though that hash function was implemented for e.g. ByteArray in Squeak, I > thought at that point the multiplication step was also implemented as a > primitive? > > Also VW marks it as a primitive, which Pharo does not. >> > > In VW it is also a translated primitive, i.e. it's executed directly in > the JIT without calling C. > > Keep in mind that the speed at which hash values are calculated is only > part of the story. If the hash function quality is not great, or the > hashed collection implementation is not efficient and induces collisions or > other extra work, improving the efficiency of the hash functions won't do > much. I think it's mentioned in the hash book (I'd have to check), but > once I made a hash function 5x times slower to get better quality and the > result was that a report that was taking 30 minutes took 90 seconds instead > (and hashing was gone from the profiler output). > > Would we gain >> some speed doing that? hashMultiply is used a lof for identity hashes. >> >> Bytecode has quite some work to do: >> >> 37 <70> self >> 38 <20> pushConstant: 16383 >> 39 <BE> send: bitAnd: >> 40 <68> popIntoTemp: 0 >> 41 <21> pushConstant: 9741 >> 42 <10> pushTemp: 0 >> 43 <B8> send: * >> 44 <21> pushConstant: 9741 >> 45 <70> self >> 46 <22> pushConstant: -14 >> 47 <BC> send: bitShift: >> 48 <B8> send: * >> 49 <23> pushConstant: 101 >> 50 <10> pushTemp: 0 >> 51 <B8> send: * >> 52 <B0> send: + >> 53 <20> pushConstant: 16383 >> 54 <BE> send: bitAnd: >> 55 <24> pushConstant: 16384 >> 56 <B8> send: * >> 57 <B0> send: + >> 58 <25> pushConstant: 268435455 >> 59 <BE> send: bitAnd: >> 60 <7C> returnTop >> > > If this is a primitive instead, then you can also avoid the overflow into > large integers and do the math with (basically) > > mov eax, smallInteger > shr eax, numberOfTagBits > mul eax, 1664525 "the multiplication that throws out the high bits" > shl eax, 4 "throw out bits 29-32" > shr eax, 4 > lea eax, [eax * 2^numberOfTagBits + smallIntegerTagBits] > > Please excuse trivial omissions in the above, it's written only for the > sake of illustration (e.g. it looks like the 3 last instructions can be > combined into two... lea followed by shr). Also, did you see the latency > of integer multiplication instructions in modern x86 processors?... > > I ran some experiments timing things. >> >> It looks like that replacing 16384 * by bitShift:14 leads to a small >> gain, bitShift (primitive 17) being faster than * (primitive 9) >> > > Keep in mind those operations still have to check for overflow into large > integers. In this case, large integers are not necessary. > > Andres. > > The bytecode is identical, except send: bitShift instead of send: * >> >> multiplication3 >> | low | >> >> low := self bitAnd: 16383. >> ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) >> bitAnd: 16383) bitShift: 14)) >> bitAnd: 16r0FFFFFFF >> >> >> >> [500000 timesRepeat: [ 15000 hashMultiply ]] timeToRun 12 >> [500000 timesRepeat: [ 15000 multiplication ]] timeToRun 41 (worse) >> [500000 timesRepeat: [ 15000 multiplication3 ]] timeToRun 10 (better) >> >> It looks like correct for SmallInteger minVal to: SmallInteger maxVal >> >> Now, VW gives: [500000 timesRepeat: [ 15000 hashMultiply ]] timeToRun >> 1.149 milliseconds >> >> Definitely worth investigating the primitive thing, or some NB Asm as >> this is used about everywhere (Collections etc). >> >> Toughts? >> >> Phil >> > >

Feb. 26, 2014

Re: [Pharo-dev] iPad version does not work ?[SEC=UNCLASSIFIED]

by phil＠highoctane.be

You can make it work following the procedure: http://www.youtube.com/watch?v=7MNsUiCc5FQ&list=UUul18dYQnhOVMfYFg6YSK4A I don't know if you will have to mess with the Xcode project afterwards at this point but I remember I had to do weird things to get Cmake to work, due to some bugs in it. So, make sure you have the right version. What I didn't got working was the simulator version. Someone having it working at this point? Phil

Feb. 26, 2014

Re: [Pharo-dev] iPad version does not work ?[SEC=UNCLASSIFIED]

by Stephen Taylor

On Tue, 2014-02-25 at 10:41 +0100, phil(a)highoctane.be wrote: > and for the rest, follow the build procedure and run on the iPad which > is connected to your Mac. That's the tricky bit - "the build procedure". There's very little mention of iOS on the Pharo web site (perhaps appropriately if it's not mature technology yet). I've looked through the FAQs, and searched for the words "ios", "iphone", "ipad" and "apple" in the website itself, in "Pharoh By Example", and in "Deep Into Pharoh", and not found a place to start. > You'll need to generate and Xcode project from Cmake to get this to > work. > Also, be ready to delete the app often on the device before running it > again as there are issues if you do not (like application not being > updated). Thanks for the tips - useful. Esteban Lorenzano wrote: > I added some hints here: > > https://github.com/pharo-project/pharo-vm Thank you - that should get me moving! Steve

Feb. 26, 2014