- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Submitted Improved Pharo Help (Case 13811) - but couldn't compare it?

by stepharo

On 9/8/14 15:07, Tim Mackinnon wrote: > Guys - Iâve incorporate the feedback from Nicolai from my previous help text submission and I thought I had the submission steps down pat - however I hit a strange problem when I was submitting my slice, and I want to check Iâm doing things right? > > My changes are very simple - 1 class method (to name my help entry) and class comment changes to improve the help text. > > I had been happily making changes and versioning them in my own local MC directory repo. > > When I went to submit my change - I didnât have a dirty package (as I had just versioned it locally) - but I donât think thats a problem right? I just created a +Slice, entered my Fobgugz number and then selected my Package by scrolling through the list of packages. > > However when I wen to compare my change against the Pharo40inbox - it kept saying that there were no changes? I donât understand that - as the inbox has my previous submission 6.mcz and something by Stefan 7.mcx - so I was expecting to see the single class method change as well as the class comment change? Did I do something wrong? You should not compare against the inbox but again the Pharo40 repo. The comparison will show you the diffs with the current Pharo head and not a random file that somebody pushed in the inbox. Because in inbox well this is an inbox. Can you rety and let us know if this solves your problem. > > To make sure, I went back - made a small text change, so that I had a dirty package, and then followed the same steps in the video - and this time it did show me a change against Pharo40Inbox, but it was just my small text change? So Iâm worried that Iâve done something funny - but I canât work out what? > > Could someone just set me straight? > > Tim >

Aug. 10, 2014

Submission problems fixed - ESUG 2014 REMINDER: 11th Innovation Technology Awards

by jdelgado＠lsi.upc.edu

We're sorry but we realized that there was a misconfiguration that prevented the submission of award candidates. It has been fixed and now it works fine. ESUG 2014 REMINDER: 11th Innovation Technology Awards http://www.esug.org/Conferences/2014/Innovation-Technology-Awards Have you written innovative Smalltalk? The developers of any Smalltalk-based software can enter by submitting a 3-5min video of their software. Entrants demo their systems in a session at the end of Monday August 18th 2014, after which the conference attendees vote. (A vote consists in providing a sorted list of 3 preferred pieces of software.) The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. The results are announced in the Awards ceremony that is held during the social event. Applicants should provide the following information on the conference registration server. Once you have registered your personal info, an 'Awards' menu allows submitting your software. You can provide this information when you first register, or login again later and update your details. The registration server will open soon. You can start preparing your software right now though. Info to provide: Name of the software Licence information (free, shareware, or commercial) Name of the Smalltalk dialect used Name, Affiliation and Country of developers Besides, it would be great if the submission could include: URL for a video (3-5 min) showing a screencast / demo of the software URL for downloading the software or at least a runnable demo Deadline: *August 15th* Any Smalltalker can apply (students, companies, ...). The presented piece of code/software should be written in Smalltalk or directly support Smalltalk (e.g. Smalltalk VM). All Smalltalk dialects are accepted. The applicant should be "strongly related" to the presented code, be it as an author, as owner of the copyright/copyleft, or as an official representative of the copyright/copyleft owner. Bests Jordi

Aug. 10, 2014

allUnimplementedCalls removed

by Pavel Krivanek

Hi Marcus, was it appropriate to remove allUnimplementedCalls from the SystemNavigation? We lost an important message to check the image health. Is there any replacement? Cheers, -- Pavel

Aug. 10, 2014

Re: [Pharo-dev] [Moose-dev] [Solved] Pharo image corruption and fatal VM error with Roassal

by Nicolai Hess

How , what caches ? 2014-08-09 0:37 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > Just use the canvas'es cache. It will ensure that you won't have problems > with session. > > > On 6 August 2014 23:52, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> In the solution I posted on the list, only TRCanvas holds the session and >> if >> it changes all attached Shapes resets its path. >> >> >> >> 2014-08-06 21:43 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> >> Thanks Vincent! >>> It seems to work well. >>> >>> Included in Roassal! >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> On Aug 6, 2014, at 12:29 PM, Blondeau Vincent < >>> vincent.blondeau(a)worldline.com> wrote: >>> >>> Solved ! >>> >>> You will found the changes in the attached .mcz. >>> >>> I added some sessions guards where some Athens external objects are >>> used. Stef you were right ;) >>> Particularly for checking the IV TRCanvas>>canvas and on TRShape>>path >>> that relies on Athens external objects. >>> >>> It seems to works for me. If it is the case for you, it we be nice to >>> integrate it quickly to be able to work fine :) >>> >>> Thanks >>> >>> Vincent >>> >>> -----Message d'origine----- >>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org >>> <pharo-dev-bounces(a)lists.pharo.org>] De la part de stepharo >>> EnvoyÃ© : jeudi 31 juillet 2014 22:58 >>> Ã : Pharo Development List >>> Objet : Re: [Pharo-dev] [Moose-dev] Pharo image corruption and fatal VM >>> error with Roassal >>> >>> Alexandre >>> >>> may be you should try to understand what is a session. >>> Because this is about 2 lines of code. >>> >>> When you open an image you save 2 min ago or 2 years ago, how the system >>> knows that an OS ressources is valid? >>> By checking the session id... >>> >>> Stef >>> >>> On 31/7/14 16:09, Alexandre Bergel wrote: >>> >>> Yes, and this is a mess. >>> I've spent quite some time in getting the session working with Roassal2 >>> and it still does not work. I would appreciate help on this. >>> >>> Alexandre >>> >>> >>> On Jul 31, 2014, at 8:58 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>> It looks like Trachel does not recreate athens external resources. >>> There is an example in AthensSceneView, on how to check and reload an >>> AthensSurface. >>> >>> >>> 2014-07-31 12:51 GMT+02:00 Usman Bhatti <usman.bhatti(a)gmail.com>: >>> >>> >>> >>> On Thu, Jul 31, 2014 at 11:17 AM, Blondeau Vincent < >>> vincent.blondeau(a)worldline.com> wrote: >>> Yes it is. But I will not do >>> >>> TRMorph allInstances do: #delete >>> >>> In command line every day... >>> >>> >>> It is only intended to recover your lost work in the image not for >>> everyday use :). >>> >>> >>> >>> >>> Vincent >>> >>> >>> >>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org >>> <pharo-dev-bounces(a)lists.pharo.org>] De la part >>> de Usman Bhatti EnvoyÃ© : jeudi 31 juillet 2014 10:59 Ã : Pharo >>> Development List Cc : Moose-related development >>> >>> >>> Objet : Re: [Pharo-dev] Pharo image corruption and fatal VM error >>> with Roassal >>> >>> >>> >>> This may be related to this known issue reported a few days back. >>> >>> https://code.google.com/p/moose-technology/issues/detail?id=1084 >>> >>> >>> >>> And there is a possible solution to recover your image. >>> >>> >>> >>> usman >>> >>> >>> >>> On Thu, Jul 31, 2014 at 10:50 AM, Blondeau Vincent < >>> vincent.blondeau(a)worldline.com> wrote: >>> >>> Hi, >>> >>> >>> >>> Yesterday, I was using GraphET (a part of Roassal) to do some charts >>> and, today, when I wanted to reopen the image. >>> >>> And I got that : >>> >>> <image001.png> >>> >>> It is *very* unpleasant... >>> >>> >>> >>> To reproduce the bug: >>> >>> 1 - You can do either: >>> >>> | builder | >>> >>> builder := GET2Line data: (0 to: 100) . >>> >>> builder >>> >>> y: [ :x | x*x ]. >>> >>> >>> >>> builder open. >>> >>> Or >>> >>> WorldMenu -> Roassal examples -> choose an item -> click on a graph . A >>> TRMorph should be opened. >>> >>> 2 - don't close the graph and save the pharo image. >>> >>> 3 - Close the pharo image >>> >>> 4 - Reopen it >>> >>> >>> >>> I am under W7 x64 with the latest moose image and the VM available on >>> the pharo.org website (http://files.pharo.org/platform/Pharo3.0-win.zip) >>> from the 10 july. >>> >>> You will find the crash dump attached. >>> >>> >>> >>> >>> >>> Thankfully, I managed to open the image with a latest VM ( >>> http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip >>> ). >>> >>> Thanks a lot Eliot ! :) >>> >>> >>> >>> And I got this: >>> >>> <image002.png> >>> >>> >>> >>> Thanks in advance >>> >>> >>> >>> Cheers, >>> >>> Vincent BLONDEAU >>> >>> >>> >>> >>> >>> >>> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã >>> l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par >>> le secret professionnel. Si vous recevez ce message par erreur, merci d'en >>> avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du >>> message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de >>> Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien >>> que les meilleurs efforts soient faits pour maintenir cette transmission >>> exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et >>> sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant >>> d'un virus transmis. >>> >>> This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive this >>> e-mail in error, please notify the sender immediately and destroy it. As >>> its integrity cannot be secured on the Internet, the Worldline liability >>> cannot be triggered for the message content. Although the sender endeavours >>> to maintain a computer virus-free network, the sender does not warrant that >>> this transmission is virus-free and will not be liable for any damages >>> resulting from any virus transmitted. >>> >>> >>> >>> >>> >>> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã >>> l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par >>> le secret professionnel. Si vous recevez ce message par erreur, merci d'en >>> avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du >>> message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de >>> Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien >>> que les meilleurs efforts soient faits pour maintenir cette transmission >>> exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et >>> sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant >>> d'un virus transmis. >>> >>> This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive this >>> e-mail in error, please notify the sender immediately and destroy it. As >>> its integrity cannot be secured on the Internet, the Worldline liability >>> cannot be triggered for the message content. Although the sender endeavours >>> to maintain a computer virus-free network, the sender does not warrant that >>> this transmission is virus-free and will not be liable for any damages >>> resulting from any virus transmitted. >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> >>> >>> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã >>> l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par >>> le secret professionnel. Si vous recevez ce message par erreur, merci d'en >>> avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du >>> message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de >>> Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien >>> que les meilleurs efforts soient faits pour maintenir cette transmission >>> exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et >>> sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant >>> d'un virus transmis. >>> >>> This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive this >>> e-mail in error, please notify the sender immediately and destroy it. As >>> its integrity cannot be secured on the Internet, the Worldline liability >>> cannot be triggered for the message content. Although the sender endeavours >>> to maintain a computer virus-free network, the sender does not warrant that >>> this transmission is virus-free and will not be liable for any damages >>> resulting from any virus transmitted. >>> <Trachel-VincentBlondeau.180.mcz> >>> _______________________________________________ >>> >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >> > > > -- > Best regards, > Igor Stasenko. >

Aug. 9, 2014

Duplicate repositories in fresh Image

by Ben Coman

Aug. 9, 2014

Re: [Pharo-dev] Submitted Improved Pharo Help (Case 13811) - but couldn't compare it?

by Ben Coman

Tim Mackinnon wrote: > Guys - Iâve incorporate the feedback from Nicolai from my previous help text submission and I thought I had the submission steps down pat - however I hit a strange problem when I was submitting my slice, and I want to check Iâm doing things right? > > My changes are very simple - 1 class method (to name my help entry) and class comment changes to improve the help text. > > I had been happily making changes and versioning them in my own local MC directory repo. > > When I went to submit my change - I didnât have a dirty package (as I had just versioned it locally) - but I donât think thats a problem right? I just created a +Slice, entered my Fobgugz number and then selected my Package by scrolling through the list of packages. > > However when I wen to compare my change against the Pharo40inbox - it kept saying that there were no changes? I donât understand that - as the inbox has my previous submission 6.mcz and something by Stefan 7.mcx - so I was expecting to see the single class method change as well as the class comment change? Did I do something wrong? > > To make sure, I went back - made a small text change, so that I had a dirty package, and then followed the same steps in the video - and this time it did show me a change against Pharo40Inbox, but it was just my small text change? So Iâm worried that Iâve done something funny - but I canât work out what? > > Could someone just set me straight? > I'm not sure of the exact expected behaviour, but I wonder what happens if you clear out your package cache direct of files, and also do "MCFileBasedRepository allSubInstances do: [ :mcfbr | mcfbr flushCache] " Disclaimer: Thats just a guess from a few minutes digging. I'm not really familiar with the architecture, and #flushCache is 'private' in MCFileBasedRepository, but also is in 'actions' in MCHttpRepository. cheers -ben > Tim > >

Aug. 9, 2014

Submitted Improved Pharo Help (Case 13811) - but couldn't compare it?

by Tim Mackinnon

Guys - Iâve incorporate the feedback from Nicolai from my previous help text submission and I thought I had the submission steps down pat - however I hit a strange problem when I was submitting my slice, and I want to check Iâm doing things right? My changes are very simple - 1 class method (to name my help entry) and class comment changes to improve the help text. I had been happily making changes and versioning them in my own local MC directory repo. When I went to submit my change - I didnât have a dirty package (as I had just versioned it locally) - but I donât think thats a problem right? I just created a +Slice, entered my Fobgugz number and then selected my Package by scrolling through the list of packages. However when I wen to compare my change against the Pharo40inbox - it kept saying that there were no changes? I donât understand that - as the inbox has my previous submission 6.mcz and something by Stefan 7.mcx - so I was expecting to see the single class method change as well as the class comment change? Did I do something wrong? To make sure, I went back - made a small text change, so that I had a dirty package, and then followed the same steps in the video - and this time it did show me a change against Pharo40Inbox, but it was just my small text change? So Iâm worried that Iâve done something funny - but I canât work out what? Could someone just set me straight? Tim

Aug. 9, 2014

NBWin32 vs OSWindows

by Tudor Girba

Hi, I am working on a little tool that requires a couple of interactions with either a command line interface or a DLL whose API I do not know :). First, I would like to thank the authors for both NBWin32 and OSWindows. Having these possibilities at our fingertips makes the difference. Second, I am still not clear how to judge the difference between these two. For example, the functionality of WinShell (from OSWindows) seems to exist one-to-one in NBWin32Shell. Is it correct to assume that I should just focus on NBWin32? Third, how do I trigger a custom command line with a blocking call and how do I capture the output of the command? For example, suppose I just need to do a "dir" and capture the output. How do I do that? Are there examples? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Aug. 9, 2014

Re: [Pharo-dev] building vm on OSX 10.9: 'features.h' not found

by Max Leske

On 09.08.2014, at 12:17, Ben Coman <btc(a)openInWorld.com> wrote: > copied to [vm-dev] Thanks Ben. > > Max Leske wrote: >> >> On 09.08.2014, at 09:20, Max Leske <maxleske(a)gmail.com> wrote: >> >> >>> On 09.08.2014, at 08:39, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >>> >>> >>>> Am 09.08.2014 um 08:13 schrieb Andreas Wacknitz <a.wacknitz(a)gmx.de>: >>>> >>>> >>>>> Hi Max, >>>>> >>>>> I had the same problems when I was building the VM for OpenSolaris. >>>>> My simple solution was to change the generated build/config.h such that the #include wonât happen: >>>>> Simply uncomment the line â#define HAVE_FEATURES_H 1â >>>>> >>>> Upps, of course comment out this line :) >>>> >>> Perfect! Thanks. >>> >> >> Lol, that wouldnât even have been necessary in my case. The problem went away as soon as I realized that I hade used #buildUnix32 instead of #buildMacOSX32â¦ *facepalm*. >> >> Because Iâm sick of doing everything by hand and reinventing the wheel every couple of weeks Iâve written a script that removes deprecated compiler flags, fixes invalid includes, updates the repo, gets the MacOSX10.6 SDK, checks for homebrew dependencies and so on. If you want to use it, just call it like so: >> >> ./build_vm_OSX10.9.sh /path/to/pharo-vm >> >> The script is in my github repo: https://github.com/theseion/stuff/blob/master/build_vm_OSX10.9.sh >> >> Feel free to copy and modify it. >> >> @Esteban >> If you want you can put it into the pharo-vm repo too. >> >> Cheers, >> Max >> >> >>> >>>>> Regards, >>>>> Andreas >>>>> >>>>> Am 09.08.2014 um 00:19 schrieb Max Leske <maxleske(a)gmail.com>: >>>>> >>>>> >>>>>> Apparently stuff has changed since I last built a VM. Now I canât get past this annoying error: >>>>>> >>>>>> -- Generating done >>>>>> -- Build files have been written to: /Users/theseion/devel/git/pharo-vm/build >>>>>> Scanning dependencies of target SqueakSSL >>>>>> [ 1%] Building C object SqueakSSL/CMakeFiles/SqueakSSL.dir/Users/theseion/devel/git/pharo-vm/src/plugins/SqueakSSL/SqueakSSL.c.o >>>>>> In file included from /Users/theseion/devel/git/pharo-vm/src/plugins/SqueakSSL/SqueakSSL.c:21: >>>>>> In file included from /Users/theseion/devel/git/pharo-vm/platforms/Cross/vm/sqVirtualMachine.h:24: >>>>>> In file included from /Users/theseion/devel/git/pharo-vm/platforms/Cross/vm/sqMemoryAccess.h:18: >>>>>> In file included from /Users/theseion/devel/git/pharo-vm/build/config.h:141: >>>>>> /Users/theseion/devel/git/pharo-vm/platforms/unix/vm/glibc.h:1:10: fatal error: 'features.h' file not >>>>>> found >>>>>> #include <features.h> >>>>>> ^ >>>>>> 1 error generated. >>>>>> make[2]: *** [SqueakSSL/CMakeFiles/SqueakSSL.dir/Users/theseion/devel/git/pharo-vm/src/plugins/SqueakSSL/SqueakSSL.c.o] Error 1 >>>>>> make[1]: *** [SqueakSSL/CMakeFiles/SqueakSSL.dir/all] Error 2 >>>>>> make: *** [all] Error 2 >>>>>> >>>>>> >>>>>> Iâve done everything suggested by the readme on github and Iâve symlinked /usr/include to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include just in case, but no luck so far. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> >>>>> >>>> >> >> >> >> >

Aug. 9, 2014

Re: [Pharo-dev] building vm on OSX 10.9: 'features.h' not found

by Ben Coman

Aug. 9, 2014