May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] I made a pass on the new website

by Marcus Denker

On 11 May 2014, at 17:34, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > > 2014-05-11 13:21 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 11 May 2014, at 10:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > Hi, > > > > I made a pass on the new website. > > I improved a bit documentation: > > - added âimmediate linksâ :P > > - added pharodocs reference link > > > > We still need to do a lot of work, but we are making improvements. > > > > Ah, I also promoted Laurentâs video to first page :) > > > > Esteban > > More changes: > > - Donation button on > http://pharo.org/get-involved > > nicer buttons for donation : > > <overviewDonationButtons.png> > Do they fit with the new design of the website? Marcus

May 11, 2014

Re: [Pharo-dev] developing games in Pharo

by Garth Holland

The LaserGame might be a good example of an app that can be easily deployed to multiple platforms. /Garth -- View this message in context: http://forum.world.st/developing-games-in-Pharo-tp4758592p4758699.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 11, 2014

Re: [Pharo-dev] Load Zinc and some packages without UI

by Johan Brichau

Hi Sebastian, Adding this around the load expression should make it work: [ ... ] on: MCMergeOrLoadWarning do: [ :ex | ex resume: true]. btw, this is the same problem that caused broken builds when I updated Grease #stable back in March Johan On 11 May 2014, at 19:55, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi list and Sven :) > > Iâd like to load some additional packages about Zinc without human intervention > > If I use this: > > Gofer it > smalltalkhubUser: 'Pharo' > project: 'MetaRepoForPharo30'; > package: 'ConfigurationOfZincHTTPComponents'; > load. > > (Smalltalk at:#ConfigurationOfZincHTTPComponents) load. > ((Smalltalk at:#ConfigurationOfZincHTTPComponents) project version: #stable) load: #('REST' 'SSO' 'WebSocket' 'Zodiac'). > > > I do get an UI asking for merge or to confirm load > > What am I doing wrong to make it automation friendly? > > sebastian > > o/ > > > > >

May 11, 2014

Re: [Pharo-dev] Load Zinc and some packages without UI

by Sven Van Caekenberghe

On 11 May 2014, at 19:55, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi list and Sven :) > > Iâd like to load some additional packages about Zinc without human intervention > > If I use this: > > Gofer it > smalltalkhubUser: 'Pharo' > project: 'MetaRepoForPharo30'; > package: 'ConfigurationOfZincHTTPComponents'; > load. > > (Smalltalk at:#ConfigurationOfZincHTTPComponents) load. > ((Smalltalk at:#ConfigurationOfZincHTTPComponents) project version: #stable) load: #('REST' 'SSO' 'WebSocket' 'Zodiac'). > > > I do get an UI asking for merge or to confirm load > > What am I doing wrong to make it automation friendly? To answer that I should try it myself, or you have to tell me what the conflict is. I believe there might be some last minute changes to Zinc packages in the released 3.0 that are not yet merged upstream, I am not sure. In any case, I would not load Zodiac. A merge is scriptable by wrapping an #on:do: around it, suppressing the merge warning. If you just want the extra's, don't load the main one. > sebastian > > o/ > > > > >

May 11, 2014

Load Zinc and some packages without UI

by Sebastian Sastre

Hi list and Sven :) Iâd like to load some additional packages about Zinc without human intervention If I use this: Gofer it smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo30'; package: 'ConfigurationOfZincHTTPComponents'; load. (Smalltalk at:#ConfigurationOfZincHTTPComponents) load. ((Smalltalk at:#ConfigurationOfZincHTTPComponents) project version: #stable) load: #('REST' 'SSO' 'WebSocket' 'Zodiac'). I do get an UI asking for merge or to confirm load What am I doing wrong to make it automation friendly? sebastian o/

May 11, 2014

file name case sensitivity

by Eliot Miranda

Hi All, being a control freak I always enable case sensitivity on my Macs. The Mac OS X file system has optional case sensitivity, insensitive by default. I once got burned with a check-out where one directory overwrite another and chose sensitivity from then on. This has caused a few problems over the years, including a Flash update that failed. No matter. Squeak has FileDirectory class>>isCaseSensitive answer a hard-coded boolean. Not good. I see this from stackoverflow<http://stackoverflow.com/questions/430256/how-do-i-determine-whether-the-fi…> : "Keep in mind that you might have multiple file systems with different casing rules. For example, the root filesystem could be case-sensitive, but you can have a case-insensitive filesystem (e.g. an USB stick with a FAT filesystem on it) mounted somewhere. So if you do such checks, make sure that you make them in the directory that you are going to access. Also, what if the user copies the data from say a case-sensitive to a case-insensitive file system? If you have files that differ only by case, one of them will overwrite the other, causing data loss. When copying in the other direction, you might also run into problems, for example, if file A contains a reference to file "b", but the file is actually named "B". This works on the original case-insensitive file system, but not on the case-sensitive system. Thus I would suggest that you avoid depending on whether the file system is case-sensitive or not if you can. Do not generate file names that differ only by case, use the standard file picker dialogs, be prepared that the case might change, etc." Luckily this is only tested in a couple of places. Most of the time the system resolves names by going through primDirectoryEntryFor: which leaves it up to the individual file system to decide (and hence get the answer right). I wonder what does FileSystem do about this? -- best, Eliot

May 11, 2014

Re: [Pharo-dev] [OT] free-to-play vs pay-to-play in mobile games

by phil＠highoctane.be

Le 11 mai 2014 18:33, "Eliot Miranda" <eliot.miranda(a)gmail.com> a Ã©crit : > > http://www.polygon.com/2014/5/9/5699058/free-to-play-mobile-candy-crush-the… > > Interesting. There may be parallels with programming language and software development environment popularity, revenue and success. I discussed the surprising low percentage of paying players with my wife as she plays a MMRPG kind of game and in some high ranked guilds it appears that some people do put $1000 plus a month into the game. I do not know if they are rich or drug lords but that is quite a figure for games. She didn't believe the figure but if it is true this is numbers game as there are hundred of thousands individuals playing the game. And then this makes a hell of a lot of cash in a recurring fashion. Phil > -- > best, > Eliot

May 11, 2014

Re: [Pharo-dev] developing games in Pharo

by phil＠highoctane.be

Le 11 mai 2014 17:22, "Eliot Miranda" <eliot.miranda(a)gmail.com> a Ã©crit : > > Hi Hilaire, > > mornin'. Thanks for such a helpful, in-depth answer! You ask about support for ARM... answer below. > > > On May 11, 2014, at 3:09 AM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > > > Morning! > > > > As several people mentioned it, I may have a few tips to share regarding > > developing educative applications with Pharo (you can read Squeak as > > well, but you may have a better support with Pharo if you want to target > > touch devices as well, I don't want to write the Squeakers are helpless > > -- not at all -- but it seems to me there are more experiences to bring > > Pharo applications on touch devices from A to Z -- from the developer to > > the consumer I mean). > > > > You are a Smalltalker so you definitely know the related benefits to > > develop with Pharo, so no need to spend words on that. You also know > > your application will be portable to the three workstation operating > > systems, very easily as the VM are routinely compiled for these hosts. > > > > To get an idea about how could look your end user application, I suggest > > you take a look at Dr.Geo - http://drgeo.eu for workstation and touch > > devices ; then also iStoa for Linux - > > https://launchpad.net/istoa/+download. These are packaged for end user. > > For Windows the installer could be improved with installed entry in the > > system menu. > > > > > >> 1) I know I have to build a suitable executable but I have never done > >> this. I have only written Smalltalk code that I then > >> use. So how do I build such an image and how big is it (assume code > >> for game is small (say 3000 lines of code)). > > > > To build the end user application, you will have to do it in two steps: > > > > 1. Prepare your image: install your source code and related source code > > package, set the state of the image, shrink your image and save it. You > > will use Metacello. I use smalltalk script for that. > > > > 2. Build your application package: you will use a pre set application > > hierarchy with the VM, icons, execution script if needed, etc and > > install your image, the necessary media and translation if any. I use > > bash script to do so. > > > > For inspiration you can have a look at Dr. Geo subversion repo[1] or > > iStoa launchpad repo[2]. The later one may be easier to follow as I gain > > some experience from Dr. Geo work. > > > > Once you setup this, building your application is easy. It is just a > > matter to update your ConfigurationOf. and executing your bash script. > > > > > >> 2) How do I get the virtual image on the customer's machine. Keep in > >> mind the customer is someone somewhere > >> on the Internet who probably knows little about how to install > >> Smalltalk or anything else. I am assuming here that > >> installing the game and installing the VM are two different tasks. > >> Is there a way to make this a single task? > > > > No installing the game and VM will be done at the same time. > > You ship your application in a zip archive or auto-installable > > executable with VM, image, and related media, documentation and > > translation files. > > > > > >> 3) So far I am assuming the target machine is Linux/Windows/Mac on a > >> Desktop/Laptop. > >> But can Smalltalk be run on any of the IPad/Notebook/etc out there? > >> These machines represent a larger game market I believe. > > > > Yes it is possible. Look at DrGeo on AppStore[3] and GooglePlay[4]. > > > > Sadly we do not have JIT support for these devices. > > Is it just a mater to support the ARM instruction set or much more > > complicated? I would be please to know. > > On iPhone Apple expressly forbid JITs other than their own so until that changes the fastest VM on iPhone will be the Stack VM. > > On Android JITs are allowed. Tim Rowledge is currently working on the Cog ARM back end which was started by Lars Wassermann, and is making good progress, working in the VM simulator. He is targeting the Raspberry Pi. I don't know whether he'll have time to port to Android, but I'm sure someone can. I don't want to talk for Tim but I expect he'll easily be finished this year. > > On a related tack, Doug McPherson has recently implemented the ARM support for Cog's FFI module, so there is now FFI support! And the Pharo team have taken on a person to work on AsmJIT for ARM. So at least on Android the Squeak/Pharo support will be good (although I expect more work is needed to provide good touch support). > > Hilaire, perhaps you can tell me whether touch support is OK or whether work needs to be done in the VM? > > > Any way for touch devices, you still have the two aspects of Smalltalk > > to consider: > > 1. The VM: it will be the interpreted VM, or COG without JIT support. > > Cog without JIT support is called the Stack VM, (since it optimizes message sending by mapping contexts to stack frames). Soon (some time this year) we should have a Spur Stack VM which may be -35% to -40% faster. > > > Esteban and Dmitry were really helpful and collaboration was great to > > let me concentrate on the image level considerations below. > > 2. Your image. > > > > For point 2, you will have extra work, better to take it into account > > since the beginning of your project if you target touch device: > > > > a) no support for multiple touch, at least as far as I know. I read > > there and there people talking or doing things, but no real stuff. > > Anyway it is definitely not a show stopper: you can be ok with tap and > > dragging. But you need to consider it. > > > > b) support for the virtual keyboard, Esteban and Dmitry added hook to > > show or hide the touch device keyboard (see drgeo code with > > showVirtualkeyboard). In your GUI design, you need to be careful your > > text zone is not hidden by the virtual keyboard. Again it is resolvable. > > > > c) the numerous screen resolutions of the touch devices. For DrGeo and > > iStoa I took very different directions. Probably the most interesting > > for you will be the one I took for iStoa. The application window is a > > full screen morph with scaled bitmap. My bitmap are scaled for a Nexus5 > > screen resolution (~2500x1600), then graphics and font are downscaled > > according to the used screen device. I suggest you take a look at the > > Linux iStoa application and resize the window to see what is happening. > > > > Using Athens is definitely not an option now for 2 reasons: it is not > > supported yet by touch devices; as long as it is not used in Pharo > > itself, if you put in perspective delivering to end user you have to > > consider it as unstable. > > > > d) native look and feel: it was really a big concern -- the bigger in > > fact -- for DrGeo. For iStoa it is nearly irrelevant, but there are > > still some widgets around. Again games does use native widget, so it may > > be ok. For DrGeo I need to subclass a Pharo theme to remove window > > decorations, force dialog to be positioned on the top and centered and > > other details I forgot about. It looks pretty ok for me, but not for > > touch device users. > > I tried to share the experience and work on this point but without > > success[5]. > > > > > >> > >> 4) Assuming I can arrange for my computer game (if I write it) to be > >> installed are there memory/cpu usage issues > >> that I need to worry about (the game itself will use a minimal of > >> memory/cpu except for graphics which also > >> is pretty reasonable). I am thinking here of IPads etc. For > >> Desktops/Laptops there should be no problem. > >> Download time and subsequent storage space is also a concern; > >> remember the device is probably used for > >> lots of other things so the amount of space allocated for games may > >> be small compared to the space on the > >> machine? > > > > If your code and medias game are small, the image size will be a > > problem, not something that will prevent your application to work > > perfectly, but more a feeling of wasted resources. > > > > With Pharo1.4, I can shrink DrGeo image below 10MB, including DrGeo > > code. With Pharo3, I can't get below 16MB with (smaller) istoa code. > > It is really a deception, the new developer tools were not developed as > > loadable code. I guess it was too difficult to be done, although it was > > a promise (informal?) of the Pharo project when it start up. > > Again it is not a show stopper. > > > > Good work on your project, I will be happy to read about its progresses. > > > > Hilaire > > > > > >> 5) Sorry for the redundancy if these questions have been asked before > >> (which I am sure they have). > >> > >> Thanks for any feedback; I am sure others are interested in this > >> question too. > >> > >> Ralph Boland > > > > > > [1] https://gforge.inria.fr/scm/?group_id=1308 > > [2] > > http://bazaar.launchpad.net/~hilaire-fernandes/istoa/trunk/files/head:/buil… > > [3] https://itunes.apple.com/us/app/dr.-geometry/id559858173?mt=8 > > [4] https://play.google.com/store/search?q=drgeo > > [5] http://forum.world.st/iOS-polymorph-theme-anyone-tt3557696.html > > > > -- > > Dr. Geo http://drgeo.eu > > Best regards, > Eliot (phone) I've had Pharo running on the iPad. Once the VM and the app- wrapping works, a key benefit is that the image is just a file to drop in the resources folder. And being able to develop on the desktop and use the image as-is on the mobile device is really a great time saver. You will have to test for the morph stepping on order to have a nice feel. Graphics and sound do work fine on iOS. I am surprised that the tools in the new Pharo are not unloadable. That's bad for image size. People look at app size and anything large has a risk of being avoided for casual apps. AAA games are gigabytes in size but that is the exception to the rule. Phil

May 11, 2014

[OT] free-to-play vs pay-to-play in mobile games

by Eliot Miranda

http://www.polygon.com/2014/5/9/5699058/free-to-play-mobile-candy-crush-the… Interesting. There may be parallels with programming language and software development environment popularity, revenue and success. -- best, Eliot

May 11, 2014

Re: [Pharo-dev] I made a pass on the new website

by Luc Fabresse

2014-05-11 13:21 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 11 May 2014, at 10:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > Hi, > > > > I made a pass on the new website. > > I improved a bit documentation: > > - added âimmediate linksâ :P > > - added pharodocs reference link > > > > We still need to do a lot of work, but we are making improvements. > > > > Ah, I also promoted Laurentâs video to first page :) > > > > Esteban > > More changes: > > - Donation button on > http://pharo.org/get-involved nicer buttons for donation : [image: Images intÃ©grÃ©es 1] Luc > > - "Commercial Supportâ section added > http://pharo.org/get-help > > - Google analytics finally configured > > Marcus >

May 11, 2014