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

Re: [Pharo-dev] ConfigurationOfIDE, ConfigurationOfMorphicUI

by Luc Fabresse

Congrats! Luc 2014-06-10 22:02 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > I were successful in two small battles on the remodularization front. > Firstly I'm able again to build image with ConfigurationOfIDE: > > > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > This job takes the shrinked image and tries to load (almost) everything > back using configuration. > > The second goal I were able to reach is to take Morphic-Core image and > load the rest of Morphic packages without tools into it (only Workspace and > Transcript are present). > > > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > Both images are still dirty and unfinished, e.g. the second one has some > repainting problems, but we move forward. > > Cheers, > -- Pavel > > >

June 11, 2014

Re: [Pharo-dev] Pharo compilation limits

by GOUBIER Thierry

Clement, Thanks for the update. Given the way the code is structured, it is a bit hard to work on catching the error: it's refactoring-based, so it prepares a set of refactorings, then applies them in one go. So, once you reach the error, you are very far from the point where you decided to produce the code. I have a working solution for now; from what you tell me, those limits will be raised in the near future and I don't have to worry too much about that. Thanks, Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de ClÃ©ment Bera [bera.clement(a)gmail.com] EnvoyÃ© : mardi 10 juin 2014 15:52 Ã : Pharo Development List Objet : Re: [Pharo-dev] Pharo compilation limits 2014-06-10 14:32 GMT+02:00 GOUBIER Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>>: Hi Clement, I'm hitting the maximum jump size limit. The method is around 10000 characters long, with a sequence of ifTrue: ifFalse: Hello, For now, this issue is hard to solve. The maximum length of a jump is 1024 instructions (cf bytecode table here: http://clementbera.wordpress.com/2013/09/23/squeakv3plusclosure-bytecode-se… ). The problem of computing the maximum bytecode length of a sequence form a parse tree is that each AST nodes may generate bytecodes of a variable length. In addition, control flow optimizations are done in Opal after the AST, therefore a block node may generate bytecodes of very different sizes. Lastly, we will change the bytecode set in a few months (partly to solve the issue you have) and your bytecode length assumptions will not be valid any more. I think the best way is to catch the error while compiling and override the error behavior. Right now a generic error is raised but it can be fixed. Look at: IRBytecodeGenerator>>jumpForward: , jumpBackward: , jump:if: Replace all the error signals by something like: self error: 'forward jump too big' ====>>> JumpTooBigCompilationError new info: specificInfosFromCompilerToTipSmaCCOnHowToGenerateWorkingCode; signal. Then you can catch it for your compilations. [ "compilation code" ] on: JumpTooBigCompilationError do: [ :ex | "exception handling code" ]. For example: [ Smalltalk compiler source: 'foo ^ nil'; class: Object; failBlock: [^ nil]; compile ] on: JumpTooBigCompilationError do: [ :ex | SmaCC new regenerateMethodBasedOn: ex info ]. However, this issue will be solved in Pharo 4 in a few months. The maximum number of instructions a jump can handle will be increased from 1024 to around 32000. If this is still not enough for you, tell us then we'll patch the compiler backend and the VM front end to work with more important instruction size. Clement Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de ClÃ©ment Bera [bera.clement(a)gmail.com<mailto:bera.clement@gmail.com>] EnvoyÃ© : mardi 10 juin 2014 08:15 Ã : Pharo Development List Objet : Re: [Pharo-dev] Pharo compilation limits 2014-06-10 2:23 GMT+02:00 GOUBIER Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>>: Hi all, anybody would have a way to determine the maximum length / maximum complexity of a method in a Pharo out of a parse tree (or whether if the parse tree is over the limit)? There are many different issues: maximum number of literals, maximum jump size, maximum number of temporaries. Can you precise what problem do you have ? What errors are raised ? The code SmaCC generates easily hit compiler limits (methods too long or too complex), and I have difficulties changing the code generation approach. For Pharo 4, we are implementing a new compiler back end that will remove some of those limits. I have a problem with code generation too and we are solving it. ClÃ©ment Thanks, Thierry

June 11, 2014

Re: [Pharo-dev] [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.43.mcz

by Eliot Miranda

On Tue, Jun 10, 2014 at 5:30 PM, gettimothy <gettimothy(a)zoho.com> wrote: > > Hi Eliot. > > > > Hi All, > > in the below, everything looks sane except configH. This looks like > an awful mistake. It appears to be capturing the output of an autoconf or > CMake run, determining things like USE_X11 USE_X11_GLX USE_QUARTZ > USE_QUARTZ_CGL USE_RFB HAVE_LIBX11 HAVE_LIBXEXT HAVE_LIBDL HAVE_DYLD > HAVE_LIBFFI etc that should be determined at VM configure time, on the host > system, immediately before compile, /not/ at source generation time. > What's going on here? > > > > > I don't know yet. That is pharo code.Let me explain my modus-operandi. > Yes, and my question was aimed at the Pharo VM folks. This part of the build process, choosing the right configuration for the host OS, is key, so it's alarming to see it presented wrongly here. I'm confident you'll take the right approach. But I was anxious to raise the issue with Igor, Esteban and anyone else who can shine a light on this. Hopefully we can fix it easily. > > First pass in the CMakeVMMakerSqueak was scripts that set up the build > environment. > > Second pass was getting the Pharo code/builds/configurations to work on > Squeak. That is done, and I have thrown that work away.(actually, it is > banished to the island of misfit toys category...) > > > Third pass is Squeak-ifying the tool to match the squeak build configs of > [OS][WordSize][Processor]/[Language][VM][MemoryManager]/[assert|assert.itimerheartbeat| > debug....etc] (i.e. build.linux32x86/squeak.cog.spur/assert) > (I also spent significant time on expanding the Builder's functionality > with an eye towards automating builds and easing use.) > > Third pass involves some very significant refactoring with each > [OS][WordSize][Processor] category having a base configuration with > dedicated [Language][VM][MemoryManager] configurations under that which can > configure themselves for [assert|assert.itimerheartbeat| debug....etc] > > My first goal in Pass 3 is to recreate Pass 2 for the builds that worked. > <----I AM HERE > > After that, I am going to look at your mvm's on the GNU side and attempt > to precisely match what you have. At that point, I will address what the > pharo code is actually doing at the configuration step. > > Then, I will be in rote-coding mode to implement that. > > However, looking at your email, I see what you mean. Those should be set > up earlier as in the first line below. > > > > test -f config.h || ../../../platforms/unix/config/configure > --without-npsqueak \ > CC="gcc -m32" \ > CXX="g++ -m32" \ > CFLAGS="$OPT -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DCOGMTVM=0" \ > LIBS="-lpthread -luuid" \ > LDFLAGS=-Wl,-z,now > ../../../scripts/nukeversion > rm -rf ../../../products/$INSTALLDIR > # prefer make install prefix=`readlink -f > \`pwd\`/../../../products/$INSTALLDIR` > # but older linux readlinks lack the -f flag > make install prefix=`(cd ../../../;pwd)`/products/$INSTALLDIR 2>&1 | tee > LOG > > > I will be back on this in the morning. Remember, I just want to recreate > Pass 2 so that I am getting CMakeLists.txt files and source code when > created. Then, I will fine tune each > Language][VM][MemoryManager]/[assert|assert.itimerheartbeat| debug....etc] > in the Linux32 tree. > At that point, we should all have a good feel for this beast and it should > be a decent tool. > > cheers. > > tty > > > > > > -- best, Eliot

June 11, 2014

Re: [Pharo-dev] [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.43.mcz

by Eliot Miranda

Hi All, in the below, everything looks sane except configH. This looks like an awful mistake. It appears to be capturing the output of an autoconf or CMake run, determining things like USE_X11 USE_X11_GLX USE_QUARTZ USE_QUARTZ_CGL USE_RFB HAVE_LIBX11 HAVE_LIBXEXT HAVE_LIBDL HAVE_DYLD HAVE_LIBFFI etc that should be determined at VM configure time, on the host system, immediately before compile, /not/ at source generation time. What's going on here? On Tue, Jun 10, 2014 at 3:15 PM, <commits(a)source.squeak.org> wrote: > > Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: > http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.43.mcz > > ==================== Summary ==================== > > Name: CMakeVMMakerSqueak-tty.43 > Author: tty > Time: 10 June 2014, 6:15:54.458 pm > UUID: af66e1e9-4379-4938-98bd-0d4b36fcda1c > Ancestors: CMakeVMMakerSqueak-tty.42 > > Added SqueakCMakeVMMakerAbstractBuilder query for available build types. > > Started (finally!) the actual build configuration construction. > > This auto-generated image is missing B2DPlugin, so I will investigate that > and return to the builds > > =============== Diff against CMakeVMMakerSqueak-tty.42 =============== > > Item was added: > + ----- Method: Linux32x86Config>>configH (in category 'squeak > compatibility') ----- > + configH > + " right now its like that " > + ^ ' > + #ifndef __sq_config_h > + #define __sq_config_h > + > + /* explicit image width */ > + > + #define HAVE_INTERP_H 1 > + > + /* package options */ > + > + #define USE_X11 1 > + #define USE_X11_GLX 1 > + /* #undef USE_QUARTZ */ > + /* #undef USE_QUARTZ_CGL */ > + /* #undef USE_RFB */ > + > + /* libraries */ > + > + /* #undef HAVE_LIBX11 */ > + #define HAVE_LIBXEXT 1 > + #define HAVE_LIBDL 1 > + /* #undef HAVE_DYLD */ > + /* #undef HAVE_LIBFFI */ > + /* #undef HAVE_ICONV */ > + > + /* #undef USE_AUDIO_NONE */ > + /* #undef USE_AUDIO_SUN */ > + /* #undef USE_AUDIO_NAS */ > + /* #undef USE_AUDIO_OSS */ > + /* #undef USE_AUDIO_MACOSX */ > + /* #undef OSS_DEVICE */ > + > + /* header files */ > + > + #define HAVE_UNISTD_H 1 > + /* #undef NEED_GETHOSTNAME_P */ > + > + #define HAVE_DIRENT_H 1 > + /* #undef HAVE_SYS_NDIR_H */ > + /* #undef HAVE_SYS_DIR_H */ > + /* #undef HAVE_NDIR_H */ > + #define HAVE_DLFCN_H 1 > + /* #undef HAVE_ICONV_H */ > + > + #define HAVE_SYS_TIME_H 1 > + #define TIME_WITH_SYS_TIME 1 > + > + #define HAVE_SYS_FILIO_H 1 > + > + /* #undef HAVE_SYS_AUDIOIO_H */ > + /* #undef HAVE_SUN_AUDIOIO_H */ > + > + /* #undef HAVE_PTY_H */ > + /* #undef HAVE_UTIL_H */ > + #define HAVE_LIBUTIL_H 1 > + /* #undef HAVE_STROPTS_H */ > + > + #define HAVE_GL_GL_H 1 > + /* #undef HAVE_OPENGL_GL_H */ > + > + /* #undef NEED_SUNOS_H */ > + > + > + #define HAVE_UUID_H > + /* system calls/library functions */ > + > + #define AT_EXIT atexit > + > + #define HAVE_TZSET 1 > + > + #define HAVE_OPENPTY 1 > + /* #undef HAVE_UNIX98_PTYS */ > + > + #define HAVE_SNPRINTF 1 > + /* #undef HAVE___SNPRINTF */ > + > + #define HAVE_MMAP 1 > + > + /* #undef HAVE_DYLD */ > + > + #define HAVE_LANGINFO_CODESET 1 > + > + #define HAVE_ALLOCA 1 > + /* #undef HAVE_ALLOCA_H */ > + > + #define HAVE_UNSETENV 1 > + > + #define HAVE_NANOSLEEP 1 > + > + /* widths of primitive types */ > + > + #define SIZEOF_INT 4 > + #define SIZEOF_LONG 4 > + #define SIZEOF_LONG_LONG 8 > + #define SIZEOF_VOID_P 4 > + > + /* structures */ > + > + #define HAVE_TM_GMTOFF 1 > + #define HAVE_TIMEZONE 1 > + > + /* typedefs */ > + > + /* #undef size_t */ > + /* #undef socklen_t */ > + > + #define squeakInt64 long long > + > + /* architecture */ > + > + #define OS_TYPE "unix" > + > + #define VM_HOST "i386-freebsd8.2" > + #define VM_HOST_CPU "i386" > + /* #undef VM_HOST_VENDOR */ > + #define VM_HOST_OS "freebsd8.2" > + #define VM_BUILD_STRING "Unix built on "__DATE__ " "__TIME__" Compiler: > "__VERSION__ > + > + /* #undef WORDS_BIGENDIAN */ > + /* #undef DOUBLE_WORD_ALIGNMENT */ > + > + /* damage containment */ > + > + /* #undef DARWIN */ > + > + #ifdef NEED_SUNOS_H > + # include "sunos.h" > + #endif > + > + /* other configured variables */ > + > + #define SQ_VERSION "3.9a-7024" > + #define VM_VERSION "3.9-7" > + #define VM_MODULE_PREFIX "" > + /* #undef VM_DLSYM_PREFIX */ > + #define VM_X11DIR "/usr/X11R6/lib" > + > + /* avoid dependencies on glibc2.3 */ > + > + /* #undef HAVE_FEATURES_H */ > + > + #if defined(HAVE_FEATURES_H) > + # include "glibc.h" > + #endif > + > + #endif /* __sq_config_h */ > + > + > > > > > > > '! > > Item was changed: > ----- Method: Linux32x86Config>>defaultExternalPlugins (in category > 'plugins') ----- > defaultExternalPlugins > + " tty 2014.06.10 cut-n-paste from > Cog/build.linux32x86/newspeak.cog.spur/build/plugins.ext" > + ^ #(B3DAcceleratorPlugin > + BochsIA32Plugin > + SqueakFFIPrims > + SqueakSSL > + LocalePlugin > + UnixOSProcessPlugin > + UUIDPlugin)! > - ^ #(SqueakSSL )! > > Item was changed: > ----- Method: Linux32x86Config>>defaultInternalPlugins (in category > 'plugins') ----- > defaultInternalPlugins > + " tty 2014.06.10 cut-n-paste from > Cog/build.linux32x86/newspeak.cog.spur/build/plugins.int" > - " cut-n-paste from Cog/build.linux32x86/newspeak.cog.v3/build" > ^ #( > AsynchFilePlugin > BMPReadWriterPlugin > B2DPlugin > BitBltPlugin > DSAPrims > DropPlugin > FileCopyPlugin > FilePlugin > FloatArrayPlugin > FloatMathPlugin > ZipPlugin > JPEGReadWriter2Plugin > JPEGReaderPlugin > LargeIntegers > Matrix2x3Plugin > MiscPrimitivePlugin > IA32ABI > RePlugin > SecurityPlugin > SocketPlugin > SurfacePlugin > UUIDPlugin > UnixOSProcessPlugin > VMProfileLinuxSupportPlugin)! > > Item was added: > + ----- Method: Linux32x86Config>>extraVMSettings: (in category 'squeak > compatibility') ----- > + extraVMSettings: maker > + self generateConfigH. > + > + > + "output a fake version.c file" > + > + self write: > + 'int vm_serial= 1; > + char *vm_date= "<HERE IS SUPPOSED TO BE THE DATE>"; > + char *cc_version= "<HERE IS SUPPOSED TO BE gcc VERSION>"; > + char *ux_version= "<FAKE FROZEN VERSION FOR DEBUGGING PURPOSES>"; > + ' > + toFile: 'version.c'. > + ! > > Item was added: > + ----- Method: Linux32x86Config>>generate (in category 'squeak > compatibility') ----- > + generate > + ^ CMakeVMGeneratorForSqueak generate: self ! > > Item was added: > + ----- Method: Linux32x86Config>>generateConfigH (in category 'squeak > compatibility') ----- > + generateConfigH > + "will fix that later" > + self write: self configH toFile: 'config.h'! > > Item was changed: > ----- Method: Linux32x86NewspeakSistaSpurConfig>>excludeFromBuild (in > category 'cmake') ----- > excludeFromBuild > "over-ride to exclude yourself from a build" > + ^true "tty 2014.06.10 not implemented on gnu side"! > - ^false! > > Item was changed: > ----- Method: Linux32x86NewspeakSistaV3Config>>excludeFromBuild (in > category 'cmake') ----- > excludeFromBuild > "over-ride to exclude yourself from a build" > + ^true "tty 2014.06.10 not implemented on gnu side"! > - ^false! > > Item was changed: > Object subclass: #SqueakCMakeVMMakerAbstractBuilder > + instanceVariableNames: 'buildTypeAndDirectoryInfo config' > - instanceVariableNames: 'buildTypeAndDirectoryInfo' > classVariableNames: '' > poolDictionaries: '' > category: 'CMakeVMMakerSqueak-Builder'! > SqueakCMakeVMMakerAbstractBuilder class > instanceVariableNames: 'default'! > > + !SqueakCMakeVMMakerAbstractBuilder commentStamp: 'tty 6/10/2014 12:46' > prior: 0! > - !SqueakCMakeVMMakerAbstractBuilder commentStamp: 'tty 6/8/2014 17:21' > prior: 0! > I am an abstract base class for various CMakeVMMakerSqueak builders. > > I am a singleton. > + I am a facade to the various > Squeak[Platform][WordSize][VM][MemoryManager]Config classes > + I provide facilities to query my configurations. > + I use the Visitor pattern in collecting information about my > configurations. > - I am a facade to the various > Squeak[Platform][WordSize][VM][MemoryManager]Config classes that provide > all the functionality. > - I also act as a repository of common information for the various > configurations. > - Think of me as lipstick on a pig. > > + Usage: > + -------------------------Using > CMakeVMMakerSqueak------------------------- > + The easiest way to use this is to utilize one of the concrete Builders > in category CMakeVMMakerSqueak-Builder. > > + With a builder, you can query it for information and then invoke it to > generate configurations and or source. > - Each one of my subclasses manages the CMakeVMMakerSqueak configurations > -------->in a specific category<-----. > - Win32Builder handles the Win32 Smalltalk Category, IOSBuilder handles > the Smalltalk IOS category. > - Yes, its a limitation of the design, but so it goes. > > + Printing or inspecting the following lines will give you a flavor of a > typical work-flow. > > + -------------Buildable/non-buildable configurations--------- > > + SqueakCMakeVMMakerAbstractBuilder showExcludeFromBuild:false > "buildable configurations" > + SqueakCMakeVMMakerAbstractBuilder showExcludeFromBuild:true. "edit > that configs 'excludeFromBuild' method to change" > + SqueakCMakeVMMakerAbstractBuilder availableBuildTypes > > + -------------------------Querying Builders and CMake > Configurations--------------- > > + SqueakLinux32X86Builder configurationsCategory > + SqueakLinux32X86Builder buildDirectory > + SqueakLinux32X86Builder availableBuilds > + SqueakLinux32X86Builder availableBuildTypesFor:(SqueakLinux32X86Builder > availableBuilds at:1) > + SqueakLinux32X86Builder availableBuildTypesFor: > #Linux32x86SqueakStackSpurConfig > + SqueakLinux32X86Builder availableBuildTypesFor: > #Linux32x86SqueakStackV3Config > + SqueakLinux32X86Builder sourceDirectoryFor:(SqueakLinux32X86Builder > availableBuilds at:1) > > + -------------------------Generating CMake files and/or Source > code------------------------- > > + SqueakLinux32X86Builder > + configureABuildFor: #Linux32x86SqueakCogV3Config withBuildType: > #debug > + generate "generate only CMake config files" > > + SqueakLinux32X86Builder > + configureABuildFor: #Linux32x86SqueakCogV3Config withBuildType: > #debug > + generateWithSources "generate configurations and invoke VMMaker > to generate source code" > > + -------------------------Compiling Instructions------------------------- > + open a terminal and go to the configurations build directory for that > configuration. (SqueakLinux32X86Builder buildDirectory) > + change into the build type subdirectory (build, build.assert, > build.debug...etc) > + source build.sh will run the build process > + executable is placed in /products folder. (SqueakLinux32X86Builder > ouputDirectory) > > ! > SqueakCMakeVMMakerAbstractBuilder class > instanceVariableNames: 'default'! > > Item was added: > + ----- Method: SqueakCMakeVMMakerAbstractBuilder > class>>availableBuildTypes (in category 'queries') ----- > + availableBuildTypes > + default ifNil:[default:= self new]. > + ^default availableBuildTypes.! > > Item was added: > + ----- Method: SqueakCMakeVMMakerAbstractBuilder class>>generate (in > category 'building') ----- > + generate > + default ifNil:[default:= self new]. > + ^default generate! > > Item was added: > + ----- Method: SqueakCMakeVMMakerAbstractBuilder > class>>generateWithSource (in category 'building') ----- > + generateWithSource > + default ifNil:[default:= self new]. > + ^default generateWithSource! > > Item was added: > + ----- Method: SqueakCMakeVMMakerAbstractBuilder>>availableBuildTypes (in > category 'queries') ----- > + availableBuildTypes > + ^self buildTypeAndDirectoryInfo keys asSortedCollection > + ! > > Item was changed: > ----- Method: > SqueakCMakeVMMakerAbstractBuilder>>configureABuildFor:withBuildType: (in > category 'building') ----- > configureABuildFor: configSymbol withBuildType: typeSymbol > + | i | > - |config i | > "Do some sanity checks, then set the internal state of a > Configuration for a particular build type. " > [ > ((Smalltalk at: configSymbol) category) = (self > configurationsCategory) "verify the class is handled by this concrete > builder" > ifTrue:[ > config := (Smalltalk at: configSymbol) > new. "verify this config can handle this build > type." > config excludeFromBuild > "has a developer excluded this build > manually?" > ifTrue:[^self > userErrorConfigMarkedAsExcludeFromBuild: configSymbol]. > i:=config availableBuilds > indexOf:typeSymbol > ifAbsent:[^self > userErrorInvalidBuildType: typeSymbol "this config does not support this > build type" > > forConfiguration: configSymbol > > hasTypes: config availableBuilds]. > config configureForBuildType: typeSymbol. > "config configure yourself" > + ^self] > - ^config] > ifFalse:[^self userErrorInvalidTarget: configSymbol] > ] ifError:[^'error configureABuildFor: ''', configSymbol]. > > ^nil. > > > ! > > Item was added: > + ----- Method: SqueakCMakeVMMakerAbstractBuilder>>generate (in category > 'building') ----- > + generate > + (config isKindOf: CPlatformConfig) > + ifTrue:[config generate] > + ! > > Item was added: > + ----- Method: SqueakCMakeVMMakerAbstractBuilder>>generateWithSource (in > category 'building') ----- > + generateWithSource > + (config isKindOf: CPlatformConfig) > + ifTrue:[config generateWithSource] > + ! > > -- best, Eliot

June 10, 2014

Re: [Pharo-dev] Windows VM question

by Nicolai Hess

As long as the libraries are accessible from the path environment variable. create directory "dll" put all dlls into that directory SET PATH=%PATH%;dll pharo.exe .... 2014-06-10 18:01 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Of course I meant I want to move those .dll files in a subdirectory. > > Thanks > > Hilaire > > Le 10/06/2014 17:55, Hilaire Fernandes a Ã©crit : > > Now I would like to hide all this *.dll files. I check for the .ini > > parameters but I did not find anything. Did I miss somethings? > > -- > Dr. Geo http://drgeo.eu > iStoa - https://launchpad.net/istoa > > >

June 10, 2014

Re: [Pharo-dev] vm over android

by Esteban A. Maringolo

2014-06-09 17:08 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Le 9 juin 2014 20:40, "Hilaire Fernandes" <hilaire.fernandes(a)gmail.com> a > Ã©crit : >> I have to admit Esteban is absolutely right. DrGeo on Android and iPad >> were very interesting experiences but it is not up to the expect level >> in term of user experience on these devices. > > Yes, same feedback here. > > For games, Monkey is a good system. http://monkeycoder.co.nz IMO, Pharo can't compete with tools for the creation of native mobile apps like Xamarin, RubyMotion or Appcelerator Titanium. Mobile is a moving target (pun unintended), and requires tons of money to at least enter into the competition. :) Esteban A. Maringolo

June 10, 2014

Re: [Pharo-dev] ConfigurationOfZincHTTPComponents class>>#catalogKeywords - can we change that a little bit?

by Sven Van Caekenberghe

And now it is published as well: === Name: ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.66 Author: SvenVanCaekenberghe Time: 10 June 2014, 10:22:30.144809 pm UUID: 7a18f667-bff7-4989-ab5f-bfefca108754 Ancestors: ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.65 fix a syntax and portability issue in the #catalogKeywords list (thx Paul DeBruicker) === On 10 Jun 2014, at 22:17, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi Sven, > > Your proposed version works just fine. Thanks for making the change, and > thanks Jenkin/TravisCI.... > > > Paul > > > > > > Sven Van Caekenberghe-2 wrote >> Hi Paul, >> >> It is good that you picked this up so quickly, since I just committed it a >> couple of hours ago. >> >> Would >> >> #catalogKeywords >> ^ #(#networking #internet #http #client #server #request #response #url >> #'mime-type' #'character-encoding') >> >> be good as well (I don't know what the limitations are in Gemstone) ? >> >> I added the hyphen on purpose, because I think that is more correct and >> better when some future tools might search through the keywords. >> >> Sven >> >> On 10 Jun 2014, at 21:57, Paul DeBruicker < > >> pdebruic@ > >> > wrote: >> >>> The current method is >>> >>> #catalogKeywords >>> ^ #(#networking #internet #http #client #server #request #response #url >>> #mime-type #character-encoding) >>> >>> >>> Can we change it to >>> >>> #catalogKeywords >>> ^ #(#networking #internet #http #client #server #request #response #url >>> #mimeType #characterEncoding) >>> >>> >>> So the GemStone parser can handle it? >>> >>> >>> Thanks >>> >>> >>> Paul > > > > > > -- > View this message in context: http://forum.world.st/ConfigurationOfZincHTTPComponents-class-catalogKeywor… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 10, 2014

Re: [Pharo-dev] ConfigurationOfZincHTTPComponents class>>#catalogKeywords - can we change that a little bit?

by Paul DeBruicker

Hi Sven, Your proposed version works just fine. Thanks for making the change, and thanks Jenkin/TravisCI.... Paul Sven Van Caekenberghe-2 wrote > Hi Paul, > > It is good that you picked this up so quickly, since I just committed it a > couple of hours ago. > > Would > > #catalogKeywords > ^ #(#networking #internet #http #client #server #request #response #url > #'mime-type' #'character-encoding') > > be good as well (I don't know what the limitations are in Gemstone) ? > > I added the hyphen on purpose, because I think that is more correct and > better when some future tools might search through the keywords. > > Sven > > On 10 Jun 2014, at 21:57, Paul DeBruicker < > pdebruic@ > > wrote: > >> The current method is >> >> #catalogKeywords >> ^ #(#networking #internet #http #client #server #request #response #url >> #mime-type #character-encoding) >> >> >> Can we change it to >> >> #catalogKeywords >> ^ #(#networking #internet #http #client #server #request #response #url >> #mimeType #characterEncoding) >> >> >> So the GemStone parser can handle it? >> >> >> Thanks >> >> >> Paul -- View this message in context: http://forum.world.st/ConfigurationOfZincHTTPComponents-class-catalogKeywor… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 10, 2014

Re: [Pharo-dev] ConfigurationOfZincHTTPComponents class>>#catalogKeywords - can we change that a little bit?

by Sven Van Caekenberghe

Hi Paul, It is good that you picked this up so quickly, since I just committed it a couple of hours ago. Would #catalogKeywords ^ #(#networking #internet #http #client #server #request #response #url #'mime-type' #'character-encoding') be good as well (I don't know what the limitations are in Gemstone) ? I added the hyphen on purpose, because I think that is more correct and better when some future tools might search through the keywords. Sven On 10 Jun 2014, at 21:57, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > The current method is > > #catalogKeywords > ^ #(#networking #internet #http #client #server #request #response #url #mime-type #character-encoding) > > > Can we change it to > > #catalogKeywords > ^ #(#networking #internet #http #client #server #request #response #url #mimeType #characterEncoding) > > > So the GemStone parser can handle it? > > > Thanks > > > Paul

June 10, 2014

ConfigurationOfIDE, ConfigurationOfMorphicUI

by Pavel Krivanek

Hi, I were successful in two small battles on the remodularization front. Firstly I'm able again to build image with ConfigurationOfIDE: https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… This job takes the shrinked image and tries to load (almost) everything back using configuration. The second goal I were able to reach is to take Morphic-Core image and load the rest of Morphic packages without tools into it (only Workspace and Transcript are present). https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… Both images are still dirty and unfinished, e.g. the second one has some repainting problems, but we move forward. Cheers, -- Pavel

June 10, 2014