April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] files.pharo.org: Moving to new server
by Stephan Eggermont April 19, 2013

April 19, 2013

Ben wrote: >I have seen mentioned that SmalltalkHub is faster than previous >repositories, but I also wonder... is there any consideration (or value) >to hooking SmalltalkHub up with a CDN ? >All uploaded mcz files are effectively static content. In the long term p2p based distribution would be much better. That fits much better with a cached CI/CD environment. And as that takes time to set up, a CDN can solve the content availability problem much sooner Stephan

1 0

[Pharo-project] [update 3.0] #30046
by Marcus Denker April 19, 2013

April 19, 2013

30046 ----- 10313 initialize SpecProxyDebugger to be able to choose it in pre-debug window https://pharo.fogbugz.com/f/cases/10313 10303 Duplicated instance #model in NewList (already defined in MorphicModel) https://pharo.fogbugz.com/f/cases/10303/ Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/NewList-MarcusDenker.26

1 0

[Pharo-project] [update 3.0] #30045
by Marcus Denker April 19, 2013

April 19, 2013

30045 ----- 10317 files.pharo.org: change image to use new update server https://pharo.fogbugz.com/f/cases/10317 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/KernelTests-MarcusDenker.484 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/UpdateStreamer-Core-MarcusDe… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Zinc-System-Support-MarcusDe…

1 0

[Pharo-project] Fwd: Old bugs fixed by Opal
by Marcus Denker April 19, 2013

April 19, 2013

Maybe of general interestâ¦ Begin forwarded message: > Hi, > > These just work with Opal correctly: > > 7202 Errors when debugging inlined values > https://pharo.fogbugz.com/f/cases/7202 > > 750 Debugger highlight bug > https://pharo.fogbugz.com/f/cases/750 > > :-) > > Marcus (The list is here: http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-compiler but this is more for boring things, e.g. commits to the repo and issue tracker status mails) Marcus

3 8

[Pharo-project] Pharo on iOS with Bluetooth keyboard working almost in full.
by phil＠highoctane.be April 19, 2013

April 19, 2013

I've made some progress on using the external keyboard. Now, it is about usable. Some mappings still missing (discovering a lot of interesting things in the process) but usable. See video (poor camera, but the better one is on the iPad, oops): http://www.youtube.com/watch?v=7MNsUiCc5FQ Phil

3 2

[Pharo-project] SS lost project description edits done in december 2012
by GÃ¶ran Krampe April 18, 2013

April 18, 2013

Hi! I moved a lot of my projects to StHub back in december, and then I edited the Project descriptions on SS to show that. But these changes have been lost I now realize? Just put it back on Phriak: http://www.squeaksource.com/Phriak.html Any idea on when/how that happened? regards, GÃ¶ran

4 3

[Pharo-project] Versionner in 2.0 again
by Norbert Hartl April 18, 2013

April 18, 2013

Yesterday I tried again to use Versionner in 2.0 but did have much success. So I tried myself (because I think Versionner is important) and could final generate a new version of my project using versionner. Following things I noticed (I'm writing this because I'm not sure which issue to open for what package. I'm just want opinions and after that I can open/upload whatever): I loaded Versionner from Metacello (taken from [1]) Gofer new url: 'http://ss3.gemstone.com/ss/Versionner'; package: 'ConfigurationOfVersionner'; load. (Smalltalk at: #ConfigurationOfVersionner) perform: #load monticello issues ============= While updating the rest of the packages to the newest I saw that Versionner-Core-Model-ChristopheDemarey.19 has an older ancestor for fixing something for pharo 1.4. The package Versionner-Core-Model-ChristopheDemarey.20 merged the packages back to HEAD but reverted some things like SystemAnnouncer back to SystemChangeNotifier. So I'm using Versionner-Core-Model-ChristopheDemarey.18 and Versionner-Core-Commands-ChristopheDemarey.17 as older packages. Any other package is the newest in the repository. metacello toolbox issues ================== I don't know much about metacello toolbox but the separation of files into ConfigurationOf and Baseline seems to have potential for confusion. There is a notion of a basename so it can build ConfigurationOfMyProject as well as BaselineOfMyProject (MyProject being the basename). But in the MetacelloToolbox in the pharo2.0 repository it does not seem right. I had to change the code to use (MBToolbox baseNameOf: â¦) at a few places. I took orientation from the message signature. If a method expects a configurationBaseName and the sender used the configuration class I changed it. I'll attach the mcz for now to this mail until it is clear what to do. versionner issues ============= At one place I added a metacello toolbox name conversion because it made sense to make it there. The other thing I had to fix is a method notification that takes the wrong entity from an announcement. Both packages attached as I don't have commit rights and don't know where the issue tracker for versionner is if there is any) I would be glad if any of you guys that know about that stuff could drop me a note if this is ok or where I've gone wrong. thanks, Norbert [1] http://users.dcc.uchile.cl/~jsandova/versionner/

8 15

[Pharo-project] Version 1.39 of Versionner
by Alexandre Bergel April 18, 2013

April 18, 2013

Hi All, I have produced a new version of Versionner (how odd is that ? :-) What is Versionner: Versionner is a French word that means handling versions. Versionner is the GUI of metacello. It supports a very simple working style: Pressing commit save all the packages of your application and it will create a new Metacello version. The goal of Versionner, is to not ever write a Metacello baseline or version by hand. A nice GUI, as it should be. What is new: - you can load a project from SmalltalkHub (cf screenshot) - some bugs have been fixed (e.g., browsing a version) - including some other fixes, from Norbert for example To load Versionner: doit in a workspace: Gofer new squeaksource3: 'Versionner'; package: 'ConfigurationOfVersionner'; load. (Smalltalk at: #ConfigurationOfVersionner) project lastVersion load. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence
by mkobetic＠gmail.com April 18, 2013

April 18, 2013

As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just experimenting with Cypress. However the master branch there is misleading, it contains a very early port of Xtreams to ST/X (there's a much more up to date version in Jan's ST/X project @ https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/) However if you look at some of the other branches in the github project you can find a fairly up to date, Cypress formatted dump from VW as well as the results of Sean's ESUG effort to add namespace-prefix mapping to Filetree (branch pharo_experiment). My ultimate goal is to test Dale's idea to maintain a cross-dialect project as parallel branches in git. However we still need to iron out various dialect differences in terms of what they emit as Cypress formatted output. BTW, does anyone know if git/github can handle absence of a master branch? I'd be inclined to just delete the master from the repository if that works well. I've been planning to ping Sean about his Filetree fixes for a while, but I need to find the time to be able to actually act on it :-). The prefix-namespace mapping is crucial to make the parallel branch approach at all feasible. There's also the Environment effort on Squeak side which may obviate the prefix mapping need, but it seems to be still in fairly early stages. So far it was mostly Nicolas' manual effort that brought VW updates over the Squeak/Pharo side. I think it was a while since the last time he's done that, so the VW port is probably ahead somewhat. But Xtreams development isn't that active anymore. Most of our Xtreams related efforts are about using them for various things, so any changes are mostly fixes or small improvements driven by that use. So in some sense a manual update could be a feasible approach at this point. But I would really like to turn the project into a more collaborative effort, where updates can flow reasonably in any direction. While I'm on the topic, I'm considering some API changes and am not sure how to go about discussing it. I don't want to cross post discussions to a number of mailing lists, so I think I'm inclined to just cross-post an invitation to anyone interested to subscribe to the Issues on the project site (https://code.google.com/p/xtreams/) and have those discussions there. Any thoughts on that? "Frank Shearar"<frank.shearar(a)gmail.com> wrote: > How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely > not the "canonical" repository, which would be in the Cincom Smalltalk > Public Repository. I think? Anyway, assuming it's up to date, one > promising approach to using Martin Kobetic's repository directly is: > * have a way of importing chunk format stuff from a GitHub repository > (see Squeak's inbox for my > doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub > (and I plan to submit a Gofer patch to do the same)) > * load into an Environment (Squeak 4.5 can do this, modulo its alpha state). > > It might even be possible to import into an Environment with the > prefix-adding import and then fileout/monticelloise the resulting > things as a prefix-using, non-Environments-requiring blob ready for > everyone to use. > > frank >

3 2

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence
by mkobetic＠gmail.com April 18, 2013

April 18, 2013

"Colin Putney"<colin(a)wiresong.com> wrote: > > While I'm on the topic, I'm considering some API changes and am not sure > > how to go about discussing it. I don't want to cross post discussions to a > > number of mailing lists, so I think I'm inclined to just cross-post an > > invitation to anyone interested to subscribe to the Issues on the project > > site (https://code.google.com/p/xtreams/) and have those discussions > > there. Any thoughts on that? > > > > That's probably the best approach: people interested in Xtreams ought > > to talk about Xtreams on the Xtreams list! > > > We may need a list eventually, but it would be kind of interesting to try > Martin's Issues approach. I guess we'd all subscribe to the Atom feed and > then "post" by opening or commenting on issues? It looks like anyone should be able to subscribe with arbitrary email address on the Issues section. Alternatively I could add people as project members if that helps. I'd like to use the Issues because that way any discussions are clearly associated and archived with the project.

1 0