Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- 3 participants
- 144622 messages
Re: [Pharo-project] Website RSS feed broken?
by Max Leske
With the last change to the rss feed I was able to reproduce the problems shown in Stefan's diff.
I'll get back to you on the status of a possible fix.
Max
On 25.10.2011, at 07:45, Stefan Marr wrote:
>
> On 19 Oct 2011, at 00:20, Max Leske wrote:
>
>> I'm looking into it.
>
>
> And it is still broken!
>
> The channel description should not change. It is meta data, and should describe, but not contain the content.
> That is one thing that could confuse RSS readers like Google Reader.
>
> But even worse is probably that the links of the items change. The guids are stable as far as I can see.
>
> The diff of the versions is below.
>
> Please fix that.
>
>
>
> Thanks
> Stefan
>
>
> --- rss1.txt 2011-10-24 22:35:32.000000000 -0700
> +++ rss2.txt 2011-10-24 22:35:43.000000000 -0700
> @@ -1,18 +1,27 @@
> <?xml version="1.0" encoding="utf-8"?>
> <?xml-stylesheet href="/_cmsbox_2.2.15_218/layout/default.css"?>
> -<?xml-stylesheet href="/_cmsbox_27/design/screen.css"?>
> +<?xml-stylesheet href="/_cmsbox_29/design/screen.css"?>
> <rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
> <channel>
> <title>Pharo Open Source Smalltalk ââ¬â News</title>
> <link>http://www.pharo-project.org/news</link>
> - <description>Pharo News Blog. Language of Languages. Pharo 1.3 and 1.4 status. Moose 4.4 release. Mailing list weekly summary #7. Pharo release 1.2.1.</description>
> + <description>Pharo News Blog. JQueryMobile for Seaside. Language of Languages. Pharo 1.3 and 1.4 status. Moose 4.4 release. Mailing list weekly summary #7.</description>
> <language>de-ch</language>
> - <lastBuildDate>Tue, 18 Oct 2011 08:57:58 GMT</lastBuildDate>
> - <pubDate>Tue, 18 Oct 2011 08:57:58 GMT</pubDate>
> + <lastBuildDate>Mon, 24 Oct 2011 13:53:17 GMT</lastBuildDate>
> + <pubDate>Mon, 24 Oct 2011 13:53:17 GMT</pubDate>
> <webMaster>alienhard(a)netstyle.ch (board)</webMaster>
> <generator>Cmsbox 2.0</generator>
> <docs>http://www.rssboard.org/rss-specification</docs>
> <item>
> + <title>JQueryMobile for Seaside</title>
> + <author>alienhard(a)netstyle.ch (board)</author>
> + <link>http://www.pharo-project.org/news?dialog=jquerymobile-for-seaside</link>
> + <pubDate>Mon, 24 Oct 2011 13:53:07 GMT</pubDate>
> + <guid isPermaLink="false">a5d13cb7-ea0d-4209-981c-6f333872ed93</guid>
> + <description><![CDATA[Nick Ager integrated JQuery Mobile with Seaside You can try it out at: http://jquerymobile]]></description>
> + <content:encoded><![CDATA[<div class="part text tall"><p class="norm">Nick Ager integrated JQuery Mobile with Seaside<br/><br/> You can try it out at: <a class="open" title="http://jquerymobile.seasidehosting.st" href="http://jquerymobile.seasidehosting.st">http://jquerymobile.seasidehosting.st </a><br/><br/>This work has been sponsored by Louis Andriese at "Delta Lloyd Online Innovations" and made available under the MIT licence. For more information, see Nick's post on the Seaside list <a class="open" title="http://lists.squeakfoundation.org/pipermail/seaside/2011-October/027772.html" href="http://lists.squeakfoundation.org/pipermail/seaside/2011-October/027772.html">here</a></p></div>]]></content:encoded>
> + </item>
> + <item>
> <title>Language of Languages</title>
> <author>alienhard(a)netstyle.ch (board)</author>
> <link>http://www.pharo-project.org/news?dialog=language-of-languages</link>
> @@ -69,7 +78,7 @@
> <item>
> <title/>
> <author>alienhard(a)netstyle.ch (board)</author>
> - <link>http://www.pharo-project.org/news?dialog=unit3782</link>
> + <link>http://www.pharo-project.org/news?dialog=unit1750</link>
> <pubDate>Thu, 24 Mar 2011 20:19:44 GMT</pubDate>
> <guid isPermaLink="false">5c8ac2aa-85c1-4a2f-98a0-1f6f2634fa6e</guid>
> <description><![CDATA[]]></description>
> @@ -78,7 +87,7 @@
> <item>
> <title/>
> <author>alienhard(a)netstyle.ch (board)</author>
> - <link>http://www.pharo-project.org/news?dialog=unit330</link>
> + <link>http://www.pharo-project.org/news?dialog=unit1114</link>
> <pubDate>Thu, 24 Mar 2011 19:09:50 GMT</pubDate>
> <guid isPermaLink="false">2ec9f57a-5efb-4e16-89ba-8dfce4fd991a</guid>
> <description><![CDATA[]]></description>
> @@ -114,7 +123,7 @@
> <item>
> <title/>
> <author>alienhard(a)netstyle.ch (board)</author>
> - <link>http://www.pharo-project.org/news?article=unit359</link>
> + <link>http://www.pharo-project.org/news?article=unit3127</link>
> <pubDate>Tue, 27 Jul 2010 07:12:13 GMT</pubDate>
> <guid isPermaLink="false">35e0919e-9c5a-4986-a981-3580482984e1</guid>
> <description><![CDATA[]]></description>
> @@ -125,7 +134,7 @@
> <author>alienhard(a)netstyle.ch (board)</author>
> <link>http://www.pharo-project.org/news?article=pharo-news-3-pharo-1-0-released</link>
> <pubDate>Thu, 15 Apr 2010 13:08:35 GMT</pubDate>
> - <guid isPermaLink="false">d72aa037-8d47-408f-9357-5037e004ec98</guid>
> + <guid isPermaLink="false">db824132-017a-4dc1-9443-903cb81a0fa0</guid>
> <description><![CDATA[Pharo is a modern open-source Smalltalk language and environment]]></description>
> <content:encoded><![CDATA[<div class="part text tall"><p class="norm">Pharo is a modern open-source Smalltalk language and environment. Pharoââ¬â¢s goals are to provide a robust and clean core and to implement innovative extensions of the language and its environment. By providing a stable and small system and excellent developer tools, Pharo is an attractive platform for mission critical Smalltalk applications.</p></div><div class="part text tall"><p class="norm">Pharo 1.0 is the first release since the project started in May 2008. Many <a class="open" title="Success stories" href="javascript:void(0)">companies</a> have already successfully adopted Pharo. <a class="open" title="http://www.seaside.st" href="http://www.seaside.st">Seaside</a>, the Smalltalk web framework, switched to Pharo as their main development platform. A <a class="open" title="http://www.pharobyexample.org" href="http://www.pharobyexample.org">book on Pharo</a> has recently been published (also available as a free PDF). Pharo has a growing <a class="open" title="Get connected, get help, contribute" href="javascript:void(0)">community</a> and is supported by research institutions such as <a class="open" title="http://www.inria.fr" href="http://www.inria.fr">INRIA</a>. Pharo is licensed under the MIT License (with some original parts remaining under the Apache License).</p></div><div class="part text tall"><p class="norm">Download the <a class="open" title="http://gforge.inria.fr/frs/download.php/26828/Pharo-1.0-OneClick.zip" href="http://gforge.inria.fr/frs/download.php/26828/Pharo-1.0-OneClick.zip">Pharo 1.0 one-click image</a> and get started within seconds. Read more about <a class="open" title="Pharo version 1.0" href="javascript:void(0)">what this release offers</a>.</p></div><div class="part text tiny"><p class="pale"><a class="open" title="http://www.adrian-lienhard.ch" href="http://www.adrian-lienhard.ch">Adrian Lienhard</a>, April 15, 2010</p></div><div class="part cb-widget tiny cb-share"><a class="cb-mail" title="Share this article on E-Mail" rel="nofollow" href="http://www.pharo-project.org/news?recommend=pharo-news-3-pharo-1-0-released"><span>Share this article on E-Mail</span></a> <a rel="nofollow" class="cb-twitter" title="Share this article on Twitter" href="http://twitter.com/home?status=I'm+currently+reading+http://www.pharo-project.org/news?article=pharo-news-3-…"><span>Share this article on Twitter</span></a> <a rel="nofollow" class="cb-facebook" title="Share this article on Facebook" href="http://www.facebook.com/sharer.php?t=Pharo News #3: Pharo 1.0 released&u=http://www.pharo-project.org/news?article=pharo-news-3-pharo…"><span>Share this article on Facebook</span></a> <a rel="nofollow" class="cb-delicious" title="Share this article on Delicious" href="http://del.icio.us/post?title=Pharo News #3: Pharo 1.0 released&url=http://www.pharo-project.org/news?article=pharo-news-3-pha…"><span>Share this article on Delicious</span></a> <a rel="nofollow" class="cb-digg" title="Share this article on Digg" href="http://digg.com/submit?title=Pharo News #3: Pharo 1.0 released&url=http://www.pharo-project.org/news?article=pharo-news-3-pha…"><span>Share this article on Digg</span></a> </div>]]></content:encoded>
> </item>
> @@ -143,7 +152,7 @@
> <author>alienhard(a)netstyle.ch (board)</author>
> <link>http://www.pharo-project.org/news?article=pharo-news-1</link>
> <pubDate>Sat, 16 Jan 2010 15:26:12 GMT</pubDate>
> - <guid isPermaLink="false">9ed28654-55a6-481b-aa7d-4d1460594d4b</guid>
> + <guid isPermaLink="false">b642fed4-fac2-4158-bf4e-059b050f5b80</guid>
> <description><![CDATA[Metacello Configurations for Pharo]]></description>
> <content:encoded><![CDATA[<div class="part lead tall"><h6>Metacello Configurations for Pharo</h6></div><div class="part text tall"><p class="norm">Mariano Martinez Peck <a class="open" title="http://lists.gforge.inria.fr/pipermail/pharo-project/2010-January/019049.ht…" href="http://lists.gforge.inria.fr/pipermail/pharo-project/2010-January/019049.ht…">announced</a> Metacello configurations for Pharo. The goal is to define a catalog of packages that are stable and known to work in Pharo. The Pharo 1.0 and forthcoming versions can be built automatically from these configurations, which are stored in a dedicated <a class="open" title="http://www.squeaksource.com/MetacelloRepository.html" href="http://www.squeaksource.com/MetacelloRepository.html">repository on SqueakSource</a>.</p></div><div class="part lead tall"><h6>Pharo Screencasts</h6></div><div class="part text tall"><p class="norm">Laurent Laffont created a blog to publish Pharo screencasts. Contact Laurent if you want to share a screencast or if you have an idea for a new screencast that Laurent can produce.</p></div><div class="part link site tall"><a class="open" href="http://pharocasts.blogspot.com/">http://pharocasts.blogspot.com/</a></div><div class="part lead tall"><h6>New Productivity Tool</h6></div><div class="part text tall"><p class="norm">Romain Robbes <a class="open" title="http://n2.nabble.com/ANN-WorkingSet-td4286093.html" href="http://n2.nabble.com/ANN-WorkingSet-td4286093.html">announced</a> WorkingSet, a small tool that helps you navigate your code in Pharo. It tracks the entities you've changed recently, and lets you access them quickly.</p></div><div class="part lead tall"><h6>Companies using Pharo</h6></div><div class="part text tall"><p class="norm">We started collecting companies that are using Pharo. 20 are already on the list ââ¬â certainly more to come soon! If your company is missing or if you have an interesting project to share, let us know!</p></div><div class="part link goto tall"><a class="open page" href="http://www.pharo-project.org/about/success-stories">http://www.pharo-project.org/about/success-stories</a></div><div class="part lead tall"><h6>New Pharo Mailing List</h6></div><div class="part text tall"><p class="norm">Since the traffic on the pharo-project mailing list is quite high and often related to the development of the Pharo core system, we created a new mailing list, <a class="open" title="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users" href="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users">pharo-users</a>, targeted to users of Pharo.</p></div><div class="part text tiny"><p class="pale"><a class="open" title="http://www.adrian-lienhard.ch" href="http://www.adrian-lienhard.ch">Adrian Lienhard</a>, January 16, 2010</p></div><div class="part cb-widget tiny cb-share"><a class="cb-mail" title="Share this article on E-Mail" rel="nofollow" href="http://www.pharo-project.org/news?recommend=pharo-news-1"><span>Share this article on E-Mail</span></a> <a rel="nofollow" class="cb-twitter" title="Share this article on Twitter" href="http://twitter.com/home?status=I'm+currently+reading+http://www.pharo-project.org/news?article=pharo-news-1"><span>Share this article on Twitter</span></a> <a rel="nofollow" class="cb-facebook" title="Share this article on Facebook" href="http://www.facebook.com/sharer.php?t=Pharo News #1&u=http://www.pharo-project.org/news?article=pharo-news-1"><span>Share this article on Facebook</span></a> <a rel="nofollow" class="cb-delicious" title="Share this article on Delicious" href="http://del.icio.us/post?title=Pharo News #1&url=http://www.pharo-project.org/news?article=pharo-news-1"><span>Share this article on Delicious</span></a> <a rel="nofollow" class="cb-digg" title="Share this article on Digg" href="http://digg.com/submit?title=Pharo News #1&url=http://www.pharo-project.org/news?article=pharo-news-1"><span>Share this article on Digg</span></a> </div>]]></content:encoded>
> </item>
>
>
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax: +32 2 629 3525
>
>
Oct. 31, 2011
[Pharo-project] How to port this code to 1.3
by Sean P. DeNigris
Old code:
Smalltalk isMorphic
ifTrue:
[self buildMorphicViewOn: aSyntaxError.
CurrentProjectRefactoring newProcessIfUI: Processor activeProcess.
^ Processor activeProcess suspend].
I started with:
self buildViewOn: aSyntaxError. "Using Polymorph?"
UIManager default spawnNewProcessIfThisIsUI: Processor activeProcess.
^ Processor activeProcess suspend.
But #spawnNewProcessIfThisIsUI: is only defined for MorphicUIManager, which
delegates to Project (I didn't know Project was even still in the image). It
seems the UIManager hierarchy needs to be cleaned, but I don't understand it
well enough. Some questions:
* why does Project still exist? It doesn't seem very useful...
* does Project play well with UIManager e.g. if DummyUIManager is active,
does Project answer nil to #uiProcess?
* is it reasonable to have a default UIManager>>#spawnNewProcessIfThisIsUI:
that doesn't do anything, and override in UIManagers with UIs?
Sean
--
View this message in context: http://forum.world.st/How-to-port-this-code-to-1-3-tp3954648p3954648.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Oct. 31, 2011
Re: [Pharo-project] Still more problems with underscore
by Levente Uzonyi
On Sun, 30 Oct 2011, Lukas Renggli wrote:
>> Hi guys. I still have problems with underscore in Pharo 1.3. I want to use
>> underscore in both ways: in selectors and as assigment.
>
> Who would tell the system what you mean?
>
>> If I do: Scanner allowUnderscoreAsAssignment: true.
>> then it works in selectrs but not in assigment.
>>
>> If I do String allowUnderscore.
>> then it works for assigment but stops working for selector.
>
> This is the point of the design. Maybe the prefix "allow" is not quite
> revealing enough, because you cannot have both.
>
> You load the old code with the setting set to true. You fix your
> broken assignments and you switch to false to use underscores.
>
> Squeak has decided to go another way and allow both cases kind of
> simultaneous. What a broken mess!
It's definitely not broken and it's far from mess. If you enable bot
preferences, then you still have an unambiguous grammar, which lets you
use undescores both in selectors and for assignment.
Levente
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
>
Oct. 31, 2011
Re: [Pharo-project] Jenkis is testing twice (or counting twice)
by Schwab,Wilhelm K
Nice catch! Things like that can be frustrating to find. But it gets to something I generally tell myself while chasing what seems to be a disproportionately stubborn defect: when Smalltalk fails, it usually does so for a "good" reason. By that, I mean that Smalltalk systems generally do just what we humans told them to do.
Bill
________________________________
From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez Peck [marianopeck(a)gmail.com]
Sent: Sunday, October 30, 2011 7:55 PM
To: Pharo-project(a)lists.gforge.inria.fr
Subject: Re: [Pharo-project] Jenkis is testing twice (or counting twice)
Well, of course the problem was mine, since I was sending a list of CATEGORIES to HDTestReport runPackages: instead of packages....
On Mon, Oct 31, 2011 at 12:44 AM, Mariano Martinez Peck <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote:
On Thu, Oct 6, 2011 at 2:49 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Mariano,
You are, of course, correct in wanting to fix it. Do the troublesome tests result in debug logs?
No, because they succeed :(
You can see it here: https://ci.lille.inria.fr/pharo/job/Fuel/465/testReport/FuelTests.InternalM…
I think it is something related to HDTestReport of HudsonBuildTools
Lukas any idea?
If not, could that be made to happen? There is no guarantee that it will show itself this way, but it might be worth a try.
Bill
________________________________________
From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>]
Sent: Wednesday, October 05, 2011 4:48 PM
To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
Subject: Re: [Pharo-project] Jenkis is testing twice (or counting twice)
On Wed, Oct 5, 2011 at 10:15 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>> wrote:
Divide by two?
*Somebody* was going to say it :)
hehehehheheh. But the problem is that you know to which packages you have to divide. Because it affects only some of them, not all ;)
On the optimistic side, the tests are being used and results reported.
________________________________________
From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>>] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com<mailto:marianopeck@gmail.com><mailto:marianopeck@gmail.com<mailto:marianopeck@gmail.com>>]
Sent: Wednesday, October 05, 2011 3:50 PM
To: Pharo Development
Subject: [Pharo-project] Jenkis is testing twice (or counting twice)
Take as an example Fuel. For 2 of the 6 packages, it runs the tests twice. Or at least they are count twice. Examples:
https://ci.lille.inria.fr/pharo/job/Fuel/369/testReport/FuelTests.Collectio…
https://ci.lille.inria.fr/pharo/job/Fuel/369/testReport/FuelTests.InternalM…
Of course, running those tests from a normal TestRunner I see the correct amount of tests.
Any ideas?
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
Oct. 31, 2011
Re: [Pharo-project] Jenkis is testing twice (or counting twice)
by Mariano Martinez Peck
Well, of course the problem was mine, since I was sending a list of
CATEGORIES to HDTestReport runPackages: instead of packages....
On Mon, Oct 31, 2011 at 12:44 AM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
>
>
> On Thu, Oct 6, 2011 at 2:49 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote:
>
>> Mariano,
>>
>> You are, of course, correct in wanting to fix it. Do the troublesome
>> tests result in debug logs?
>>
>
> No, because they succeed :(
>
> You can see it here:
> https://ci.lille.inria.fr/pharo/job/Fuel/465/testReport/FuelTests.InternalM…
>
> I think it is something related to HDTestReport of HudsonBuildTools
>
> Lukas any idea?
>
>
> If not, could that be made to happen? There is no guarantee that it will
>> show itself this way, but it might be worth a try.
>>
>> Bill
>>
>>
>> ________________________________________
>> From: pharo-project-bounces(a)lists.gforge.inria.fr [
>> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano
>> Martinez Peck [marianopeck(a)gmail.com]
>> Sent: Wednesday, October 05, 2011 4:48 PM
>> To: Pharo-project(a)lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] Jenkis is testing twice (or counting twice)
>>
>> On Wed, Oct 5, 2011 at 10:15 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu
>> <mailto:bschwab@anest.ufl.edu>> wrote:
>> Divide by two?
>>
>> *Somebody* was going to say it :)
>>
>> hehehehheheh. But the problem is that you know to which packages you have
>> to divide. Because it affects only some of them, not all ;)
>>
>> On the optimistic side, the tests are being used and results reported.
>>
>>
>>
>>
>> ________________________________________
>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:
>> pharo-project-bounces(a)lists.gforge.inria.fr> [
>> pharo-project-bounces(a)lists.gforge.inria.fr<mailto:
>> pharo-project-bounces(a)lists.gforge.inria.fr>] On Behalf Of Mariano
>> Martinez Peck [marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>]
>> Sent: Wednesday, October 05, 2011 3:50 PM
>> To: Pharo Development
>> Subject: [Pharo-project] Jenkis is testing twice (or counting twice)
>>
>> Take as an example Fuel. For 2 of the 6 packages, it runs the tests
>> twice. Or at least they are count twice. Examples:
>>
>>
>> https://ci.lille.inria.fr/pharo/job/Fuel/369/testReport/FuelTests.Collectio…
>>
>> https://ci.lille.inria.fr/pharo/job/Fuel/369/testReport/FuelTests.InternalM…
>>
>> Of course, running those tests from a normal TestRunner I see the correct
>> amount of tests.
>>
>> Any ideas?
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
--
Mariano
http://marianopeck.wordpress.com
Oct. 30, 2011
Re: [Pharo-project] Jenkis is testing twice (or counting twice)
by Mariano Martinez Peck
On Thu, Oct 6, 2011 at 2:49 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote:
> Mariano,
>
> You are, of course, correct in wanting to fix it. Do the troublesome
> tests result in debug logs?
>
No, because they succeed :(
You can see it here:
https://ci.lille.inria.fr/pharo/job/Fuel/465/testReport/FuelTests.InternalM…
I think it is something related to HDTestReport of HudsonBuildTools
Lukas any idea?
If not, could that be made to happen? There is no guarantee that it will
> show itself this way, but it might be worth a try.
>
> Bill
>
>
> ________________________________________
> From: pharo-project-bounces(a)lists.gforge.inria.fr [
> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano
> Martinez Peck [marianopeck(a)gmail.com]
> Sent: Wednesday, October 05, 2011 4:48 PM
> To: Pharo-project(a)lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Jenkis is testing twice (or counting twice)
>
> On Wed, Oct 5, 2011 at 10:15 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu
> <mailto:bschwab@anest.ufl.edu>> wrote:
> Divide by two?
>
> *Somebody* was going to say it :)
>
> hehehehheheh. But the problem is that you know to which packages you have
> to divide. Because it affects only some of them, not all ;)
>
> On the optimistic side, the tests are being used and results reported.
>
>
>
>
> ________________________________________
> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:
> pharo-project-bounces(a)lists.gforge.inria.fr> [
> pharo-project-bounces(a)lists.gforge.inria.fr<mailto:
> pharo-project-bounces(a)lists.gforge.inria.fr>] On Behalf Of Mariano
> Martinez Peck [marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>]
> Sent: Wednesday, October 05, 2011 3:50 PM
> To: Pharo Development
> Subject: [Pharo-project] Jenkis is testing twice (or counting twice)
>
> Take as an example Fuel. For 2 of the 6 packages, it runs the tests twice.
> Or at least they are count twice. Examples:
>
>
> https://ci.lille.inria.fr/pharo/job/Fuel/369/testReport/FuelTests.Collectio…
>
> https://ci.lille.inria.fr/pharo/job/Fuel/369/testReport/FuelTests.InternalM…
>
> Of course, running those tests from a normal TestRunner I see the correct
> amount of tests.
>
> Any ideas?
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
--
Mariano
http://marianopeck.wordpress.com
Oct. 30, 2011
Re: [Pharo-project] Smalltalk Job in L.A.
by blake
I've seen it a couple of places but this fellow called and emailed me:
Kapil_Gupta(a)artechinfo.com
===Blake===
On Sun, Oct 30, 2011 at 12:52 AM, Noury Bouraqadi <bouraqadi(a)gmail.com>wrote:
> Hi,
>
> Do you have link or a contact email for the job offrer ?
> On 29 oct. 2011, at 18:28, blake wrote:
>
> > Hey, guys--
> >
> > There's a job opening with Sempra, some kind of energy company, in the
> Los Angeles area (Marina Del Rey, Monterey Park--you can Google the
> locations), that requires C++ and Smalltalk.
> >
> > ===Blake===
>
> Noury
> --
> http://twitter.com/#!/NouryBouraqadi
>
>
>
>
>
>
Oct. 30, 2011
Re: [Pharo-project] Is RPackage dead?
by Tudor Girba
Hi,
On 30 Oct 2011, at 22:43, Igor Stasenko wrote:
> On 30 October 2011 23:05, Tudor Girba <tudor(a)tudorgirba.com> wrote:
>> Hi,
>>
>> Wait. The RPackage should not hold more than one category. That is the whole point. If you will allow mapping more than one category to an RPackage, we will either never get rid of categories or we will enter into the messy territory of nested packages. At this time, we certainly do not want the former, and we cannot afford the later.
>>
>> Please, let's keep it simple. There is no point allowing people to create mess by default. There is no practical use case for having this extra stuff. In fact, we know from experience that if we want to manage a larger than trivial system, we need strict conventions. Anything else pretty much fails in the long run.
>>
> I think you looking at this at wrong angle.
I strongly disagree :).
> People can create a mess with any software, no matter what good it is.
Sure. But, the thing is that just because mess is possible, you do not want to make it easy.
> If you deny people from doing the mess within the package , you are
> not solving the problem - you just shifting it into another plane - a
> package management.
> So you forcing people to do the mess at package management level. Fine :)
> But personally, I fail to see why mess with package management
> (dependencies, load order etc) is better than single bloated package
> with lots of categories.
>
> Because, imposing any strict naming rules is like trying to swim against stream.
> If i want a _single_ package with two categories, like:
> - core
> - utils
>
> give me a strong reason why i can't have it, and why i have to waste
> my time with package management, if all i need is single package?
So now I think you are looking at the problem in a strange way. You seem to argue that we should optimize the system around toy examples. Almost anything meaningful requires more than that. Let's optimize around what matters.
And regarding wasting time, you will waste much less than now at the moment when Monticello will become transparent as well. In other words, you will simply stay in your code browser and load and publish from there. No mess, no fuss. But to get there easily, we need this 1-to-1 between what is publishable and what is in the image.
Perhaps where you will need some attention is loading order, but when Metacello will get a better integration, many things will be possible. But, we need a stable and simple base.
Cheers,
Doru
>
>> So, I come back to my point. At this point, we can safely load RPackage in the image (actually, in the Moose image, it is always loaded) and have tools be built on top of them. Then in Pharo 1.5 or later we start transitioning by not allowing people to commit more than one Category/RPackage in a Monticello package.
>>
>> It's a smooth transition that can be spread over a longer period of time.
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 30 Oct 2011, at 15:29, Stéphane Ducasse wrote:
>>
>>> I agree now this is the path to arrive there that is important to me.
>>>
>>> Stef
>>>
>>> On Oct 30, 2011, at 3:23 PM, Igor Stasenko wrote:
>>>
>>>> Stephane, as i said before, i do not see problems with RPackage / naming.
>>>> These things are orthogonal, as to me.
>>>> We can keep naming scheme as we use today, but switch to RPackage.
>>>>
>>>> A package can keep the list of category names and that's it. They
>>>> could even be completely different, if people want it.
>>>> Say, package is named
>>>> Foo
>>>> and contain categories:
>>>> 'Foo-Core'
>>>> 'Bar'
>>>>
>>>> The rationale is simple:
>>>> it is up to human(s) to decide what a package should contain, and what
>>>> names to use. Let's just embrace the imperfection and do not dictate
>>>> people
>>>> how they should name their categories in order to make sure that
>>>> classes in that categories will be put into concrete package.
>>>> If people like to confuse themselves with category names, not matching
>>>> the package name , it should be their own choice and responsibility.
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko.
>>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Reasonable is what we are accustomed with."
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
--
www.tudorgirba.com
"What we can governs what we wish."
Oct. 30, 2011
Re: [Pharo-project] Is RPackage dead?
by Igor Stasenko
On 30 October 2011 23:05, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Hi,
>
> Wait. The RPackage should not hold more than one category. That is the whole point. If you will allow mapping more than one category to an RPackage, we will either never get rid of categories or we will enter into the messy territory of nested packages. At this time, we certainly do not want the former, and we cannot afford the later.
>
> Please, let's keep it simple. There is no point allowing people to create mess by default. There is no practical use case for having this extra stuff. In fact, we know from experience that if we want to manage a larger than trivial system, we need strict conventions. Anything else pretty much fails in the long run.
>
I think you looking at this at wrong angle.
People can create a mess with any software, no matter what good it is.
If you deny people from doing the mess within the package , you are
not solving the problem - you just shifting it into another plane - a
package management.
So you forcing people to do the mess at package management level. Fine :)
But personally, I fail to see why mess with package management
(dependencies, load order etc) is better than single bloated package
with lots of categories.
Because, imposing any strict naming rules is like trying to swim against stream.
If i want a _single_ package with two categories, like:
- core
- utils
give me a strong reason why i can't have it, and why i have to waste
my time with package management, if all i need is single package?
> So, I come back to my point. At this point, we can safely load RPackage in the image (actually, in the Moose image, it is always loaded) and have tools be built on top of them. Then in Pharo 1.5 or later we start transitioning by not allowing people to commit more than one Category/RPackage in a Monticello package.
>
> It's a smooth transition that can be spread over a longer period of time.
>
> Cheers,
> Doru
>
>
>
> On 30 Oct 2011, at 15:29, Stéphane Ducasse wrote:
>
>> I agree now this is the path to arrive there that is important to me.
>>
>> Stef
>>
>> On Oct 30, 2011, at 3:23 PM, Igor Stasenko wrote:
>>
>>> Stephane, as i said before, i do not see problems with RPackage / naming.
>>> These things are orthogonal, as to me.
>>> We can keep naming scheme as we use today, but switch to RPackage.
>>>
>>> A package can keep the list of category names and that's it. They
>>> could even be completely different, if people want it.
>>> Say, package is named
>>> Foo
>>> and contain categories:
>>> 'Foo-Core'
>>> 'Bar'
>>>
>>> The rationale is simple:
>>> it is up to human(s) to decide what a package should contain, and what
>>> names to use. Let's just embrace the imperfection and do not dictate
>>> people
>>> how they should name their categories in order to make sure that
>>> classes in that categories will be put into concrete package.
>>> If people like to confuse themselves with category names, not matching
>>> the package name , it should be their own choice and responsibility.
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Reasonable is what we are accustomed with."
>
>
>
--
Best regards,
Igor Stasenko.
Oct. 30, 2011
Re: [Pharo-project] Is RPackage dead?
by Tudor Girba
Hi,
Wait. The RPackage should not hold more than one category. That is the whole point. If you will allow mapping more than one category to an RPackage, we will either never get rid of categories or we will enter into the messy territory of nested packages. At this time, we certainly do not want the former, and we cannot afford the later.
Please, let's keep it simple. There is no point allowing people to create mess by default. There is no practical use case for having this extra stuff. In fact, we know from experience that if we want to manage a larger than trivial system, we need strict conventions. Anything else pretty much fails in the long run.
So, I come back to my point. At this point, we can safely load RPackage in the image (actually, in the Moose image, it is always loaded) and have tools be built on top of them. Then in Pharo 1.5 or later we start transitioning by not allowing people to commit more than one Category/RPackage in a Monticello package.
It's a smooth transition that can be spread over a longer period of time.
Cheers,
Doru
On 30 Oct 2011, at 15:29, Stéphane Ducasse wrote:
> I agree now this is the path to arrive there that is important to me.
>
> Stef
>
> On Oct 30, 2011, at 3:23 PM, Igor Stasenko wrote:
>
>> Stephane, as i said before, i do not see problems with RPackage / naming.
>> These things are orthogonal, as to me.
>> We can keep naming scheme as we use today, but switch to RPackage.
>>
>> A package can keep the list of category names and that's it. They
>> could even be completely different, if people want it.
>> Say, package is named
>> Foo
>> and contain categories:
>> 'Foo-Core'
>> 'Bar'
>>
>> The rationale is simple:
>> it is up to human(s) to decide what a package should contain, and what
>> names to use. Let's just embrace the imperfection and do not dictate
>> people
>> how they should name their categories in order to make sure that
>> classes in that categories will be put into concrete package.
>> If people like to confuse themselves with category names, not matching
>> the package name , it should be their own choice and responsibility.
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
Oct. 30, 2011