February 2016 - Pharo-users

Re: [Pharo-users] rollToArity: ?

by Esteban Lorenzano

Iâm not happy with the method name, but I think is well explained in method comments: ExternalAddress>>rollToArity: arity "This will 'roll' a pointer to a certain arity. What does this means? Let's say I have a method who will be called with a ** arity: method: aPointer self ffiCall: #( method ( MyExternalObjectClass **aPointer) ) This usually means that method will put a pointer in the address of aPointer. And what I actually want is this pointer. So I do Something like this: p := MyExternalObjectClass new. self mehod: p. And I expect to have 'p' correctly initialised on return. Well... tha's not so simple :) When compiling #method:, UnifiedFFI needs to first 'roll' the pointer (which means to take a pointer of a pointer of a pointer... as many pointers as arity solicited), and then, after call, it needs to 'unroll' all this pointers (see #unrollFromArity: method) â ByteArray>>rollToArity: arity "This is complicated... I assuming this ways of calling a function: arity == 1: ----------- ByteArray works as pointer buffer of single pointer to something: ex 1) buffer := ByteArray new: 4. self ffiCall: #( void function (int *buffer) ). ex 2) buffer := 'Hello, World' asByteArray. self ffiCall: #( void function (char *buffer) ). arity > 1: ---------- ByteArray works as pointer to allocate results: ex 1) pointer := ByteArray new: (FFIExternalType pointerSize). self ffiCall: #( void function ( char **answer )). In this case this will not work fine because content of ByteArray needs to be a pointer too, and then it needs to be allocated in the heap... while this could be managed, I'm puting for the moment just an error and a recommendation of using an ExternalAddress. " basically, is the equivalent of â&â operator in C. you can manually do the same by doing: | var | var := 42 pointer. who will give you a byte array with signedLongAt: 1 == 42. â¦ but since old NB was doing this implicitly, we need to provide it too :) Esteban ps: Why do you need to know it? This is internal in UnifiedFFI so nobody should need to deal with it. > On 17 Feb 2016, at 16:43, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Esteban, > > What Object>>rollToArity: is supposed to do? It belongs to UnifiedFFI > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Feb. 18, 2016

Re: [Pharo-users] [squeak-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

by Esteban Lorenzano

> On 16 Feb 2016, at 08:38, John Pfersich <jpfersich(a)gmail.com> wrote: > > FYI. I noticed that Eliot didn't send to Pharo-users. not needed because we have a different process: pharo users will have a VM immediately without noticing :) (in fact we already had the 5 months of bug fixes integratedâ¦ what we still do not have is the 64bits build butâ¦ since we do not have 64bits images yet this is not a problem :P) Esteban > > > Sent from my iPad > > Begin forwarded message: > >> From: Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> >> Date: February 15, 2016 at 11:39:29 PST >> To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org <mailto:vm-dev@lists.squeakfoundation.org>> >> Cc: "newspeaklanguage(a)googlegroups.com <mailto:newspeaklanguage@googlegroups.com>" <newspeaklanguage(a)googlegroups.com <mailto:newspeaklanguage@googlegroups.com>>, Discusses Development of Pharo <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org <mailto:squeak-dev@lists.squeakfoundation.org>> >> Subject: [squeak-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602 >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org <mailto:squeak-dev@lists.squeakfoundation.org>> >> >> Hi All, >> >> first of all, apologies for the long wait for new VMs. I know there are bugs that these VMs address and that it's been 5 months since VMs were last made is something I regret. The wait was due to my developing the 64-bit Spur Cog JIT VM which required surgery not just to the Cogit but also to Slang. I beg your forgiveness. >> >> Secondly, the Mac VMs are much changed, using John McIntosh's Cocoa support libraries. The old Carbon UI VMs are history. That means that Cog supports building on contemporary Mac OS releases. These VMs were built on 10.9; I like the 3D look much more than the 10.10 one ;-). The VMs are also signed, so installing them should be easier. >> >> Thirdly, these VMs include 64-bit JIT support. There is an updated squeak trunk image at http://www.mirandabanda.org/files/Cog/SpurImages <http://www.mirandabanda.org/files/Cog/SpurImages> for you to try. As yet the 64-bit Vms do not include an FFI plugin. I hope to rectify this soon. >> >> Finally I have included Pharo Mac VMs, not to displace the official Pharo VMs, but to test my build process. I hope that in very few months the svn repository will be moed to githup and that Esteban and I will build official VMs from the same repository. >> >> >> >> The VMs are here: http://www.mirandabanda.org/files/Cog/VM/VM.r3602 <http://www.mirandabanda.org/files/Cog/VM/VM.r3602> >> >> CogVM binaries as per VMMaker.oscog-eem.1679/r3602 >> >> Include 64-bit Spur VMs for Mac OS X x64 and Linux x64. N.B. As yet these VMs >> lack FFI support. >> >> Move all Mac OS X VMs to the Cocoa libraries. Minimum supported version should >> be 10.6.x. The Mac OS X VMs are signed and so should install properly without >> having to disable the launch security checks. >> >> >> Bug Fixes and Improvements: >> >> General: >> Add vmParameter 20 to answer the utc microseconds at startup. >> >> >> CoInterpreter: >> Remove the atCache from the CoInterpreter. It's of little benefit given the >> Cogit. >> >> ceSend: et al need to add looked up methods to the method cache, otherwise >> methods only found through machine code sends will not be jitted. >> >> Fix slip in maybeSelectorOfMethod: which will improve back traces >> including methods containing pragmas (including primitives). >> >> Modify secret primtiive 161, primitiveSetIdentityHash so that with 0 args it >> answers whether an object has an identity hash. This is vacuously true for V3, >> but is meaningful in Spur. >> >> >> Cogit: >> Fix /horrible/ bug with primitive error codes and fixups. The adjustment of the >> initialPC to skip the primitive and error code, if any, was done after >> generating fixups for backward branches, and hence these branches were bogus. >> Object>>shallowCopy in Spur is subject to this, but amazingly enough it has not >> surfaced before now. Fix this by adjusting the initialPC before scanMethod >> scans for fixups. >> >> Fix bug in Spur machine-code at:put: on 32-bit bits objects; method failed to >> fail for negative values. >> >> Fill unused portions of methods with the stop instruction, not nop. >> >> Explicitly initialize the code zone with stops. Explicitly clear the >> reclaimed portion of the method zone after a compaction. >> >> Include the reclaimed portion of the method zone in the I-cache flush >> after a compaction: no point in leaving it in cache since it isn't a >> valid call/jump target. >> >> >> Spur: >> Maintain the survivor count on scavenge. >> >> Fix start up of images containing >= 16 segments. The old code assumed >> numSegments < 16 and failed to grow the segment records, resulting in objects >> in segments greater than 15 to not be swizzled, and a resulting crash. >> >> Spur Cogit: Support CompiledMethod indexing in genPrimitiveAt[Put]. Hence fix >> the regression in at:[put:] whereby in Spur one could access the literals part >> of a method as bytes. >> Add a machine-code primitive for objectAt: to provide fast literal and header >> access on Spur. >> >> Add 16-bit indexability to Spur. Generate slimmer code for >> positive32BitValueOf: on 64-bit Spur. >> >> Fix a bug with out-of-place two-way become, which got the hash copy the wrong >> way round. By default, the hash stays with the reference in two-way become. >> >> Fix what appears to be a compiler bug with in-place two-way-become by treating >> the headers to be swapped so that remembered flags are swapped and hash bits >> are swapped if required. This fixes a bug with in-place two-way become of >> objects that are the same size on the heap. One object's contents would not >> be updated correctly. >> >> Implement ephemeron queue primitive. Add an image flag that controls the >> finalization support (StackInterpreter instVar newFinalization). If unset, >> finalization is as currently expected; WeakArray finalizes all WeakArrays in >> its registries on each finalization (which does not scale!). If set, then both >> fired ephemerons and bereaved weak arrays are added to the finalization queue >> and the finalization semaphore is signalled. In this regime the image is >> expected to send mourn to each element of the queue, and weak arrays will send >> themselves finalize in mourn, side-stepping the finalizeValues steps and >> rendering WeakArray's FinalizationDependents and WeakRegistry obsolete. >> The bit is set via >> Smalltalk vmParameterAt: 48 >> put: ((Smalltalk vmParameterAt: 48) bitOr: 64). >> >> >> Slang: >> Fix bad regression in type inference from VMMaker.oscog-eem.1587. >> returnTypeForSend:in: can only default return types to sqInt for unknown >> selectors. The rewrite in VMMaker.oscog-eem.1587 inadvertently defaulted the >> return type of known methods whose return type was yet to be determined to >> sqInt. The fix is to only default to sqInt if there is no known method for the >> given selector. This fixes, for instance, the weird flipping of the type of >> 32-bit Spur's headerWhileForwardingOf:,which should always be #sqLong. >> >> Fix bad bug in type inferrence. Avoid computing variable and return types >> prematurely i.e. don't derive types from as-yet-untyped methods. >> >> Fix baaaad bug in node:typeCompatibleWith:inliningInto:in: which was looking >> up the type of the formal parameter in inlining in the target method, not the >> method being inlined! >> >> >> Newspeak: >> Fix bug in MNU for cogged dynamic super sends - should start looking for >> #doesNotUnderstand: in the superclass not the receiver class. Unify MNU >> lookup between absent and present receiver sends as a result. >> >> Further fix outer send MNU by not confusing lkupClass and lkupClassTag. >> Push setting lkupClassTag down to clarify it is for new cache entries. >> >> >> Plugins: >> Fix the FilePlugin's unnecessary fullGC on Spur. >> Include the file sync prim in the FilePrims plugin. >> >> ThreadedFFIPlugin: >> - ExternalAddress now are taken correctly (nor as ByteArray or Alien, because >> they are different beasts). >> - allow pushing of pointers to any type (into a ByteArray, an ExternalAddress >> or an Alien), to allow passing parameters style int*, float*, etc. >> - allow reading in memory to allow read chunks of ByteArray >> >> Added ThreadedFFIPlugin>>#primitiveLoadSymbolFromModule (copy and adapt from >> IA32ABIPlugin). >> >> Fix coercion problems on FFI plugin (IA32 & ARM) >> - character were not correctly mapped back >> - floats were not being well checked >> - external addressed needs to be treated as aliens for the purpose of coercing >> them as pointers (bad regression by Eliot) >> >> Alien Plugins: >> Fix missing primitive failure for Alien typeAt: 0 [put:]. >> Add word accessors to Alien. >> >> _,,,^..^,,,_ >> best, Eliot >>

Feb. 18, 2016

Re: [Pharo-users] cleaning up Pharo images

by Marcus Denker

Hi, There is right now a bug that images *never* shrink. https://pharo.fogbugz.com/f/cases/17240/Spur-When-saving-an-image-it-never-… For Pharo4: > On 18 Feb 2016, at 11:20, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > is there a way to minimize/clean up Pharo image/changes files after an application has been installed into it? > > Currently I have the base image sitting at 65MB and changes at 36MB, which is massive considering only source code was added. > > I've tried running 'Smalltalk cleanUp: true', which I cannot run from command line because it asks a questionâ¦ can this be circumvented? > For cleanup, there is Smalltalk cleanUp: true except: #() confirming: false. to not get asked questions. There is class ImageCleaner that does some more things (most have been move to #cleanUp methods already, though): ImageCleaner cleanUpForRelease This is called e.g. after each build on the CI server. It Yes, via the command line: ./pharo Pharo.image clean --release ImageCleaner cleanUpForProduction unloads all tests, examples and documentation. This leads to a much smaller image, but as we do not regression test it, it might be broken. > Running it manually however has driven the image size down to 46MB, not changing the .changes file however. > > Are there other ways to make the image smaller? > Do I need such massive changes file? Can't I just empty it completely? > In theory you can use PharoChangesCondenser condense but in practice this is run once per year and it never working when called... We need to get rid of the .changes and .sources mechanism. We need to reach a point where âthe artefact on the CI server is the artefact of releaseâ. Mechanism of the kind âand then we can this method one day before releaseâ is not a good idea. Marcus

Feb. 18, 2016

cleaning up Pharo images

by Peter UhnÃ¡k

Hi, is there a way to minimize/clean up Pharo image/changes files after an application has been installed into it? Currently I have the base image sitting at 65MB and changes at 36MB, which is massive considering only source code was added. I've tried running 'Smalltalk cleanUp: true', which I cannot run from command line because it asks a questionâ¦ can this be circumvented? Running it manually however has driven the image size down to 46MB, not changing the .changes file however. Are there other ways to make the image smaller? Do I need such massive changes file? Can't I just empty it completely? Thanks, Peter

Feb. 18, 2016

Re: [Pharo-users] GSOC 2016 Application update

by Sven Van Caekenberghe

> On 18 Feb 2016, at 08:43, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Thanks to the amazing works of Peter and Uko, > we have always an updated gsoc web page here: http://gsoc.pharo.org/ > everytime you will edit the gsoc ideas topics list : > https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics… > > The html web page is automatically generated, tested and updated > thanks to a Travis job: > https://travis-ci.org/pharo-project/pharo-project-proposals > > Thank you guys ! +1000 Beautiful teamwork ! > On Wed, Feb 17, 2016 at 9:27 AM, Serge Stinckwich > <serge.stinckwich(a)gmail.com> wrote: >> Dear all, >> >> just a quick update to GSOC application of Pharo this year >> >> - We have enough topics I guess. I already send a reminder on the >> various mailing-list. >> List of topics here: >> https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics… >> >> We have to generate the html from the topics list and put the result >> on the gsoc.pharo,org website. I ask Uko to have a look to this, but I >> don't want to loose to much time on this. I was wondering if we should >> transform the list as a Markdown document on github just to keep it >> simple. >> >> - Finish the 2016 Application and Organization profile on Google >> website. The questions are a little bit different from 2015 and we >> should complete them. >> Please find below the answers to the questions right now. >> >> I add in parenthesis, the number of words of each answers and the >> maximum allowed. >> >> Please us to refine our answers. We need to wrote "guidance for students". >> >> Thank you. >> >> ========================================================================== >> >> Why does your org want to participate in Google Summer of Code? (898/1000) >> >> Supporting open-source projects is one of the most important >> objectives of the Pharo community. Participating at GSoC will increase >> the visibility of Pharo project efforts, thus favoring interactions >> with other communities. We are also interested in providing >> interesting projects to students allowing them to learn and have a fun >> job for the summer. >> >> We expect also to bring more people into our community. That's very >> interesting as the Pharo community is trying to be innovation-driven >> and more open minded than the Smalltalk community from which we have >> evolved. We want people from other communities to join ours and we are >> also interested in what is happening outside and to share experiences >> or ideas. Fortunately for us, dynamic languages like Python, Ruby, >> among others, enjoy increasing popularity. This is an excellent >> opportunity to join, show and learn from and with other communities. >> >> ========================================================================== >> >> How many potential mentors have agreed to mentor this year? >> >> 11-15 >> >> ========================================================================== >> >> How will you keep mentors engaged with their students? (668/1000) >> >> We chose mentors from people who are long time in our community and >> have proven to be reliable. Usually we try to match mentors with >> projects that are important for themselves. This means that the mentor >> has an own interest in the project that the student doing it. Also we >> try to ensure that there is a co-mentor for every project who can >> replace the main mentor if needed. Also it is very important for us to >> keep a good record and expand the community, and in previous years we >> even managed to organize our own "summer code" programs for a couple >> of students, so in the worst case we will find a replacement from the >> core part of the community, or the board itself. >> >> ========================================================================== >> How will you help your students stay on schedule to complete their >> projects? (886/1000) >> >> As mentioned before we've already organized our own small "summer >> code" programs, as usually we have more interested students than the >> fundings that we can spend for them. However we acknowledge that >> maintaining student's motivation is very important. We are a very open >> and friendly community, and we encourage the students to take part on >> the mailing list discussions from the beginning of their projects. >> There is a specific pharo-users mailing-list more suitable for >> beginners than the pharo-dev mailing-list. >> Usually students get feedback and requests from the beginning of their >> projects, and they have people interested in the prototypes as soon as >> they are ready. From our experience having real users for the project >> serves as the best motivation. Also our mentors try to maintain a >> constructive and friendly discussion to ensure that the student enjoys >> working on the project. >> >> ========================================================================== >> >> How will you get your students involved in your community during GSoC? >> (608/1000) >> >> As mentioned above we encourage students to announce their status on >> the mailing list as well as discuss questions on our Slack channel. We >> also encourage them to write blogs about their project experience to >> both promote themselves and give others an opportunity to familiarize >> with the project more and share ideas between students. We are >> organizing PharoDays every year (this year in Belgium, website: >> http://pharodays2016.pharo.org) and we participate to the ESUG >> (European Smalltalk User Group) conference in the end of each summer >> and plan to invite the students of the best projects to present there. >> >> ========================================================================== >> >> Has your org been accepted as a mentoring org in Google Summer of Code before? >> >> Yes >> >> ========================================================================== >> >> Which years did your org participate in GSoC? >> >> - 2012 >> - 2010 >> - 2008 >> - 2007 >> >> ========================================================================== >> >> What is your success/fail rate per year? >> >> - 2012: 10 projects pass / 3 fail >> - 2010: 6 projects pass / 0 fail >> - 2008: 5 projects pass / 0 fail >> - 2007: 5 projects pass / 0 fail >> >> >> ========================================================================== >> >> If your org has applied for GSoC before but not been accepted, select the years: >> >> - 2015 >> - 2014 >> - 2013 >> >> ========================================================================== >> >> What year was your project started? >> >> 2008 >> >> ========================================================================== >> >> Short description of Pharo (166/180) >> >> Pharo is a pure object-oriented programming language and IDE. We >> innovate every part of the development experience to come up with the >> best way to work with software. >> >> ========================================================================== >> >> Long description of Pharo (1401/2000) >> >> Pharo is a pure object-oriented programming languagea and IDE. >> Pharo's goal is to minify the gap between the state of your mind and >> the functionality of your application. Whether you are writing code, >> debugging it, inspecting an object, hacking the runtime or tweaking >> the IDE there should be nothing that stops you from engaging the >> action with ease and grace. >> >> We work both on improving Pharo itself and on developing end user >> applications in Pharo. Below you will see the highlights of most >> prominent Pharo features. >> >> ### Simple & powerful language >> No constructors, no types declaration, no interfaces, no primitive >> types. Yet a powerful and elegant language with a full syntax fitting >> in one postcard! Pharo is objects and messages all the way down. >> >> ### Feel a live environment >> Feel the joy of having immediate feedback at any moment of your >> development: Developing, testing, debugging. Even in production >> environments, you will never be stuck in compiling and deploying steps >> again! >> >> ### Amazing debugging experience >> The Pharo environment includes a debugger unlike anything you've seen >> before. It allows you to step through code, restart the execution of >> methods, create methods on the fly, and much more! >> >> ### Pharo is yours >> Pharo is made by an incredible community, with more than 80 >> contributors for the last revision of the platform and hundreds of >> people contributing constantly with frameworks and libraries. >> >> ========================================================================== >> >> Guidance for students on how to apply to your organization. Should >> include any prerequisites or requirements. You may wish to include a >> template or tips for their proposals. >> >> (0/1500) >> >> TBD >> >> ========================================================================== >> >> - >> >> Regards, >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

Feb. 18, 2016

[ANN] OSUnix and OSLinuxUbuntu on new UFFI

by Torsten Bergmann

Sebastian wrote: >I just know that Windows users should not replace their current images with the latest >images yet. Otherwise they might have trouble. One always might have trouble when one uses the latest beta image and CI built VM. No need to warn about this. Nonetheless: ============ Using #50586 image with the "living on the edge" Spur VM (http://files.pharo.org/vm/pharo-spur32/win/PharoVM-Spur32-win-latest.zip last built 17.02.2016 18:53) there is a reproducable case when one opens the browser and selects a method in a class browser and then another method of the same class. This crashes the VM. Using the latest "stable" Spur VM it will work: http://files.pharo.org/vm/pharo-spur32/win/stable-20160203.zip Use that VM version until issue #17541 is solved. Keep on reporting - but please next time stay away from hijacking non-related threads and give more details: In the world menu there is "System" -> "System Reporter". In this reporter the "Image" as well as the "VM General" is already selected. With this you can find out and report exactly the VM/image combination that you used. You should provide this in future bug reports. For other "Non-Pharo VM crashing" bugs it is enough to report just the image version (which can be easily seen also in World menu "System" -> "About". Also it makes more sense to report such findings to the developer list (who usually work on latest and greatest). Bye Torsten (without h)

Feb. 18, 2016

Re: [Pharo-users] GSOC 2016 Application update

by Serge Stinckwich

Thanks to the amazing works of Peter and Uko, we have always an updated gsoc web page here: http://gsoc.pharo.org/ everytime you will edit the gsoc ideas topics list : https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics… The html web page is automatically generated, tested and updated thanks to a Travis job: https://travis-ci.org/pharo-project/pharo-project-proposals Thank you guys ! On Wed, Feb 17, 2016 at 9:27 AM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Dear all, > > just a quick update to GSOC application of Pharo this year > > - We have enough topics I guess. I already send a reminder on the > various mailing-list. > List of topics here: > https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics… > > We have to generate the html from the topics list and put the result > on the gsoc.pharo,org website. I ask Uko to have a look to this, but I > don't want to loose to much time on this. I was wondering if we should > transform the list as a Markdown document on github just to keep it > simple. > > - Finish the 2016 Application and Organization profile on Google > website. The questions are a little bit different from 2015 and we > should complete them. > Please find below the answers to the questions right now. > > I add in parenthesis, the number of words of each answers and the > maximum allowed. > > Please us to refine our answers. We need to wrote "guidance for students". > > Thank you. > > ========================================================================== > > Why does your org want to participate in Google Summer of Code? (898/1000) > > Supporting open-source projects is one of the most important > objectives of the Pharo community. Participating at GSoC will increase > the visibility of Pharo project efforts, thus favoring interactions > with other communities. We are also interested in providing > interesting projects to students allowing them to learn and have a fun > job for the summer. > > We expect also to bring more people into our community. That's very > interesting as the Pharo community is trying to be innovation-driven > and more open minded than the Smalltalk community from which we have > evolved. We want people from other communities to join ours and we are > also interested in what is happening outside and to share experiences > or ideas. Fortunately for us, dynamic languages like Python, Ruby, > among others, enjoy increasing popularity. This is an excellent > opportunity to join, show and learn from and with other communities. > > ========================================================================== > > How many potential mentors have agreed to mentor this year? > > 11-15 > > ========================================================================== > > How will you keep mentors engaged with their students? (668/1000) > > We chose mentors from people who are long time in our community and > have proven to be reliable. Usually we try to match mentors with > projects that are important for themselves. This means that the mentor > has an own interest in the project that the student doing it. Also we > try to ensure that there is a co-mentor for every project who can > replace the main mentor if needed. Also it is very important for us to > keep a good record and expand the community, and in previous years we > even managed to organize our own "summer code" programs for a couple > of students, so in the worst case we will find a replacement from the > core part of the community, or the board itself. > > ========================================================================== > How will you help your students stay on schedule to complete their > projects? (886/1000) > > As mentioned before we've already organized our own small "summer > code" programs, as usually we have more interested students than the > fundings that we can spend for them. However we acknowledge that > maintaining student's motivation is very important. We are a very open > and friendly community, and we encourage the students to take part on > the mailing list discussions from the beginning of their projects. > There is a specific pharo-users mailing-list more suitable for > beginners than the pharo-dev mailing-list. > Usually students get feedback and requests from the beginning of their > projects, and they have people interested in the prototypes as soon as > they are ready. From our experience having real users for the project > serves as the best motivation. Also our mentors try to maintain a > constructive and friendly discussion to ensure that the student enjoys > working on the project. > > ========================================================================== > > How will you get your students involved in your community during GSoC? > (608/1000) > > As mentioned above we encourage students to announce their status on > the mailing list as well as discuss questions on our Slack channel. We > also encourage them to write blogs about their project experience to > both promote themselves and give others an opportunity to familiarize > with the project more and share ideas between students. We are > organizing PharoDays every year (this year in Belgium, website: > http://pharodays2016.pharo.org) and we participate to the ESUG > (European Smalltalk User Group) conference in the end of each summer > and plan to invite the students of the best projects to present there. > > ========================================================================== > > Has your org been accepted as a mentoring org in Google Summer of Code before? > > Yes > > ========================================================================== > > Which years did your org participate in GSoC? > > - 2012 > - 2010 > - 2008 > - 2007 > > ========================================================================== > > What is your success/fail rate per year? > > - 2012: 10 projects pass / 3 fail > - 2010: 6 projects pass / 0 fail > - 2008: 5 projects pass / 0 fail > - 2007: 5 projects pass / 0 fail > > > ========================================================================== > > If your org has applied for GSoC before but not been accepted, select the years: > > - 2015 > - 2014 > - 2013 > > ========================================================================== > > What year was your project started? > > 2008 > > ========================================================================== > > Short description of Pharo (166/180) > > Pharo is a pure object-oriented programming language and IDE. We > innovate every part of the development experience to come up with the > best way to work with software. > > ========================================================================== > > Long description of Pharo (1401/2000) > > Pharo is a pure object-oriented programming languagea and IDE. > Pharo's goal is to minify the gap between the state of your mind and > the functionality of your application. Whether you are writing code, > debugging it, inspecting an object, hacking the runtime or tweaking > the IDE there should be nothing that stops you from engaging the > action with ease and grace. > > We work both on improving Pharo itself and on developing end user > applications in Pharo. Below you will see the highlights of most > prominent Pharo features. > > ### Simple & powerful language > No constructors, no types declaration, no interfaces, no primitive > types. Yet a powerful and elegant language with a full syntax fitting > in one postcard! Pharo is objects and messages all the way down. > > ### Feel a live environment > Feel the joy of having immediate feedback at any moment of your > development: Developing, testing, debugging. Even in production > environments, you will never be stuck in compiling and deploying steps > again! > > ### Amazing debugging experience > The Pharo environment includes a debugger unlike anything you've seen > before. It allows you to step through code, restart the execution of > methods, create methods on the fly, and much more! > > ### Pharo is yours > Pharo is made by an incredible community, with more than 80 > contributors for the last revision of the platform and hundreds of > people contributing constantly with frameworks and libraries. > > ========================================================================== > > Guidance for students on how to apply to your organization. Should > include any prerequisites or requirements. You may wish to include a > template or tips for their proposals. > > (0/1500) > > TBD > > ========================================================================== > > - > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 18, 2016

[ANN] Pharo Sprint 26 Feb

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Friday, 26 Feb, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on Slack or the IRC channel #pharo on irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

Feb. 18, 2016

Re: [Pharo-users] [ANN] OSUnix and OSLinuxUbuntu on new UFFI

by Sebastian Heidbrink

Hi Thorsten, I had already filed a bug report and the topic is under investigation. I saw your post and I do not have further details yet, I just know that Windows users should not replace their current images with the latest images yet. Otherwise they might have trouble. I wrote that Pharo images listed in the Launcher do not work. I did not mention a particular combination of configurations. I am sorry that I hijacked your thread. I work on all platforms but I used Windows only past 4 days. If you would like to follow the bug please visit: https://pharo.fogbugz.com/f/cases/17541/PharoVM-crash-in-Moose-6-0-image-wh… Unfortunately, this issue is brand new and I couldn't write more details on that except warm to wait for further info before upgrading images on Windows 8. Sebastian On 2016-02-17 5:11 PM, Torsten Bergmann wrote: > Sebastian wrote: >> I don't want to spoil the great news, but actually the most recent >> changes break Pharo 5.0 with SpurVM on Windows 8. >> ... >> >> I tried several older snapshots of the VM and the Pharo images listed in >> the PharoLauncher but none work. > Seriously you should rethink your way of COMMUNICATION: > > 1. This thread here is about a specific UNIX package and you tell us about a > general Pharo problem you seem to have on a completely different platform: WINDOWS. > => ???? > > 2. You "hijack" this thread instead of opening a separate one specific > to the problem and asking if others might have the same issue. > => ???? > > 3. You "give a general warning" to others already to "keep their images"? > No details on what modification could possibly harm the image. > => ???? > > 4. You talk about a broken Pharo 5 - but do not tell us what/where it is broken. > Did the image not come up, is there a problem in a tool or when calling > something/using UFFI. > => ???? > > 5. You talk about "recent changes" without telling us when it started or at > a minimum with which image version you face the problem. When it worked > before then one can easily use Launcher to incrementally download and check > several images to find out which change broke something. > => ???? > > 6. You say you cant build a new image since a few days without giving any > information what packages you load or how you build your custom images. > => ???? > > 7. You said that you used several combination of VM and images but > do not tell us which one you used/expected to work. > => ???? > > Sorry - do you really think this is a good way to report a problem? > How do you expect someone to invest his sparse spare time to help you? > Maybe it is much easier to "just lament" instead of "being supportive". > > As an info: I also use Pharo 5 (even latest images up to Pharo 5 #50586) on Windows > with Spur since 2 months. Found smaller issues that I reported, most of them are > already adressed because I was able to give a clear picture of what the problem was. > > And yes - times are a little bit shaky because of Spur and UFFI - but this > was already announced/warned before and situation has improved a lot with > latest updates. > > Please do us all a favour and open a new thread or much better a bug > report with exact details to reproduce if you have any finding. > > Before that check your setup: for SpurVM you should try: > http://files.pharo.org/vm/pharo-spur32/win/stable-20151214.zip (which is the Spur build from December) > http://files.pharo.org/vm/pharo-spur32/win/PharoVM-Spur32-win-latest.zip (which is the latest CI built) > with the highest image build number: http://files.pharo.org/image/50/ > > For non-spur images (Pharo 4.0 and Pharo 5.0 up 50496 update) you need the old > non-spur VM: http://files.pharo.org/vm/pharo/win/ > > If you use Launcher check that you use the latest green build from https://ci.inria.fr/pharo/view/Launcher > and that spur and non-spur Vm is correctly configured in the Pharo launcher settings. > > Thanks > Torsten > >

Feb. 18, 2016

[ANN] OSUnix and OSLinuxUbuntu on new UFFI

by Torsten Bergmann

Sebastian wrote: >I don't want to spoil the great news, but actually the most recent >changes break Pharo 5.0 with SpurVM on Windows 8. >... > >I tried several older snapshots of the VM and the Pharo images listed in >the PharoLauncher but none work. Seriously you should rethink your way of COMMUNICATION: 1. This thread here is about a specific UNIX package and you tell us about a general Pharo problem you seem to have on a completely different platform: WINDOWS. => ???? 2. You "hijack" this thread instead of opening a separate one specific to the problem and asking if others might have the same issue. => ???? 3. You "give a general warning" to others already to "keep their images"? No details on what modification could possibly harm the image. => ???? 4. You talk about a broken Pharo 5 - but do not tell us what/where it is broken. Did the image not come up, is there a problem in a tool or when calling something/using UFFI. => ???? 5. You talk about "recent changes" without telling us when it started or at a minimum with which image version you face the problem. When it worked before then one can easily use Launcher to incrementally download and check several images to find out which change broke something. => ???? 6. You say you cant build a new image since a few days without giving any information what packages you load or how you build your custom images. => ???? 7. You said that you used several combination of VM and images but do not tell us which one you used/expected to work. => ???? Sorry - do you really think this is a good way to report a problem? How do you expect someone to invest his sparse spare time to help you? Maybe it is much easier to "just lament" instead of "being supportive". As an info: I also use Pharo 5 (even latest images up to Pharo 5 #50586) on Windows with Spur since 2 months. Found smaller issues that I reported, most of them are already adressed because I was able to give a clear picture of what the problem was. And yes - times are a little bit shaky because of Spur and UFFI - but this was already announced/warned before and situation has improved a lot with latest updates. Please do us all a favour and open a new thread or much better a bug report with exact details to reproduce if you have any finding. Before that check your setup: for SpurVM you should try: http://files.pharo.org/vm/pharo-spur32/win/stable-20151214.zip (which is the Spur build from December) http://files.pharo.org/vm/pharo-spur32/win/PharoVM-Spur32-win-latest.zip (which is the latest CI built) with the highest image build number: http://files.pharo.org/image/50/ For non-spur images (Pharo 4.0 and Pharo 5.0 up 50496 update) you need the old non-spur VM: http://files.pharo.org/vm/pharo/win/ If you use Launcher check that you use the latest green build from https://ci.inria.fr/pharo/view/Launcher and that spur and non-spur Vm is correctly configured in the Pharo launcher settings. Thanks Torsten

Feb. 18, 2016