- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Who invented Nautilus Groups (DynamicGroup/DynamicClassGroup)

by Nicolai Hess

2014-02-03 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > On 03 Feb 2014, at 20:57, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I don't get why a DynamicGroup manages a list of methods and not a list > of classes like DyanmicClassGroup. > > > Me for the title. > > And to answer shortly, to have groups with a finer grained definition. > > > If Nautilus tries to create the class list from a DyanicGroup group it > takes > awful long time if this Groups have more than 20-30 different classes > > > Then maybe the correct kind of group should be used. > Ben > > Ok, thanks. (I am not sure if this is easily fixable, I don't know where to make this distinction). Nicolai

Feb. 4, 2014

Re: [Pharo-dev] PharoProjectCatalog for Pharo 3?

by HernÃ¡n Morales Durand

Thank you Torsten! If you want to integrate, I have attached changes to CatalogBuilder methods for redirecting to MetaRepoForPharo3. I don't know the proper way to test it yet CatalogBuilder new generateAll ?? but gives me a MessageNotUnderstood: GoferResolvedReference>>load Cheers HernÃ¡n 2014-02-03 Torsten Bergmann <astares(a)gmx.de>: > HernÃ¡n wrote: > >I have noticed the following catalog url lists configurations for Pharo > 2.0 > > > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/ > ? > > > >Is there a job/url for configurations for Pharo 3? > > > Not yet, AFAIK Catalog had to be adopted manualy for MetaRepoForPharo30. > > Code is on > http://smalltalkhub.com/mc/DamienCassou/Pier-Gutemberg/main > > if you like to adopt. > > Thanks > T. > > > > >

Feb. 4, 2014

Re: [Pharo-dev] Zodiac and IMAP

by Sven Van Caekenberghe

Hi Torsten, On 04 Feb 2014, at 00:18, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Sven, > > while there is support for SMTP and POP3 in Zodiac I wonder > about IMAP protocol support. > > Thx > T. I am not sure I understand the question. Yes, there are ZdcSecurePOP3Client and ZdcSecureSMTPClient as subclasses of existing implementations of POP3 and SMTP respectively. As far as I know, there is no IMAP client in the image, yet. Zodiac only adds the 'secure' part, not the implementation proper. It would be nice to have IMAP client/server support though ;-) Sven

Feb. 4, 2014

Zodiac and IMAP

by Torsten Bergmann

Hi Sven, while there is support for SMTP and POP3 in Zodiac I wonder about IMAP protocol support. Thx T.

Feb. 4, 2014

Re: [Pharo-dev] PharoProjectCatalog for Pharo 3?

by Torsten Bergmann

HernÃ¡n wrote: >I have noticed the following catalog url lists configurations for Pharo 2.0 >https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? >Â >Is there a job/url for configurations for Pharo 3? Not yet, AFAIK Catalog had to be adopted manualy for MetaRepoForPharo30. Code is onÂ http://smalltalkhub.com/mc/DamienCassou/Pier-Gutemberg/main if you like to adopt. Thanks T. Â Â Â

Feb. 4, 2014

Re: [Pharo-dev] Who invented Nautilus Groups (DynamicGroup/DynamicClassGroup)

by Benjamin

On 03 Feb 2014, at 20:57, Nicolai Hess <nicolaihess(a)web.de> wrote: > I don't get why a DynamicGroup manages a list of methods and not a list > of classes like DyanmicClassGroup. Me for the title. And to answer shortly, to have groups with a finer grained definition. > If Nautilus tries to create the class list from a DyanicGroup group it takes > awful long time if this Groups have more than 20-30 different classes Then maybe the correct kind of group should be used. Ben

Feb. 3, 2014

OpalCompiler and Semantic analyzer

by Nicolai Hess

Can someone with some background knowledget on the opal compiler, look at my fix for issue 12442. It seems to work, but I don't like it. There were 2 problems with OCUnusedVariableWarning, removing unused temps: 1. Removes the RBTemporaryNode and updates the source text but does not correct the sourcetext offset of the remaining nodes. 2. Removed temporaries are left in the methodnode/blocknode scope One additional issue, if you have removed all temporaries, the two bars from the empty variable declaration still there nicolai

Feb. 3, 2014

Re: [Pharo-dev] test failures in downloaded image 30733

by Usman Bhatti

On Sun, Feb 2, 2014 at 2:43 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 02 Feb 2014, at 14:31, btc(a)openinworld.com wrote: > > > For diligence and curiosity leading up to the Pharo3 release, I > downloaded build image 30733 (with PharoLauncher) > > Getting an image green is a lot of little, trivial, hard work... and green > always means "Green in this context". Just headless vs. non-headless > changes a lot, for example. > > Another wonderful thing is that tests are fine when run individually, but > fail when running all tests. > > We need to think about automatic UI testing... > It will be awesome to have automatic UI tests. Currently, I can go as far as invoking the UI but then to complete the fields in another process/thread, I haven't really spent enough time. I think that's already discussed on the mailing list but some time I should have a look. Automated tests before a release/roll-out will be a dream coming true ;-). Usman > > Loading an external package changes *everything*. We do not have a a > release criterium that all tests are green after loading external packages. > > > and immediately ran all tests, which reported 7 failures and 1 error > (see attached snapshot). Now presumably these did not occur in the CI > build since otherwise it would not have been available to PharoLauncher, so > this raises a few questions/ideas: > > > > 1. Why the discrepancy / how did these slip through ? Perhaps some > difference in local environment / difference in VM? Can anyone else > reproduce this for 30733? I've logged an new case [1] for this where I > plan to either link to existing cases or add a subcase for each failure. > Please add your results there, particularly if you see a known issue. > > > > Here are my failures... > > BlockClosureTest>>#testTrace > > Not failing for me > > > JobTest>>#testCurrent > Not failing for me > > > MetacelloRepositorySqueakCommonTestCase>>#testAsRepositorySpecFor > > MetacelloRepositorySqueakCommonTestCase>>#testDirectoryRepository > > MetacelloRepositorySqueakCommonTestCase>>#testFileTreeRepository > Not failing fo rme > > > ReleaseTest>>#testObsoleteClasses > > Not failing for me > > SimmulateMouseSpecification>>#testSimulateRightClick > yes, that is failing > > > and errors... > > OpenToolTest>>#testOpenBrowseOnInstalledTraitMethod > > > yes. > > The last two are examples of UI tests that are not run on the Build server > in a way that they could fail. > > > 3. Assuming Pharo3 will go through a Release Candidate phase, > > Normally the idea is that we will just release. In the past we used an > elaborate process, but the reality is that nobody looks at release > candidates. > You can tell 5 times that the release candidate will be released unchanged > and people should check: they will not. They will download > the release, though, and then complain that the "obvious" thing X is not > fixed that that the people who managed the release process did > everything wrong. Because "release" means bug free. By magic. > > Marcus >

Feb. 3, 2014

Who invented Nautilus Groups (DynamicGroup/DynamicClassGroup)

by Nicolai Hess

I don't get why a DynamicGroup manages a list of methods and not a list of classes like DyanmicClassGroup. If Nautilus tries to create the class list from a DyanicGroup group it takes awful long time if this Groups have more than 20-30 different classes (see issue 12780).

Feb. 3, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Eliot Miranda

On Sat, Feb 1, 2014 at 3:25 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Andreas > > did you realise that pools are just static cached version of (simple > value) returning messages? > But they are not. They are combinations of a getter and a setter; pools are pools of *variables*, not *constants*. So one variable is replaced by one variable and two methods, in turn adding two symbols. Personally I want to continue to be able to write opcode caseOf: { "Noops & Pseudo Ops" [Label] -> [maxSize := 0]. [AlignmentNops] -> [maxSize := (operands at: 0) - 1]. [Fill16] -> [maxSize := 2]. [Fill32] -> [maxSize := 4]. [FillFromWord] -> [maxSize := 4]. [Nop] -> [maxSize := 1]. ... not opcode caseOf: { "Noops & Pseudo Ops" [CogRTLOpcodes label] -> [maxSize := 0]. [CogRTLOpcodes alignmentNops] -> [maxSize := (operands at: 0) - 1]. [CogRTLOpcodes fill16] -> [maxSize := 2]. [CogRTLOpcodes fill32] -> [maxSize := 4]. [CogRTLOpcodes fillFromWord] -> [maxSize := 4]. [CogRTLOpcodes nop] -> [maxSize := 1]. ... And I don't want to have to define the accessors. It's bloat. It's less readable. Theres still a pool involved (CogRTLOpcodes's classPool); it is just being made harder to get hold of. Pools are really useful. Just because someone's only worked on projects where the need didn't present itself doesn't mean they're not really useful when they can be used. One could say the same about contexts. Should we get rid of them because most people hardly ever use them? >> How many lectures did you give? It is annoying to have to explain > something that usually people do not need to know. > > I don't give any lectures to students but I often try to "teach" > Smalltalk to some of my colleagues and friends. And with that I have hard > times. > > Typically "experienced" software developers think about themselves as > being experts in object orientation and programming languages, > > even if they have only experiences with C, C# and C++. "Teaching" them > about Smalltalk's idea of object orientation is VERY hard, almost > > impossible because they already know everything (read: they are > ignorant) and lazy. I guess there are some similarities to students. > > So, no I don't teach but have my own problems ;-) > > So when you learn a new language like python do you get all the syntax to > create a class as a template? > Or just the non optional parts? > To me smalltalk class definition forgot the be designed, else variables > would have been first class objects like in CLOS MOP > > >>>> Newcomers don't use a lot of things but that should not be a reason > to hide them. In my experience newcomers need guidance and rules but > > "oldtimers" need freedom. > > and? you still can use Pool even if I do not really understand why we need > them since we have classes and messages. > Because Pool are just a static version of that. Did I miss something > obvious? > Pool may have they place in 1980 to optimize for speed but I would be > curious to see if a modern languages using a decent JIT > would keep them. Especially since class names should be dynamically looked > up. > > > This is one of the reasons I really enjoy dynamic typing and Smalltalk. > I don't like to obey to artificial rules that only > > put permanent burden to me in order to protect me from something I might > do wrong sometimes. > > You are mixing things. So I will not comment on it. > > > At the moment I am considering pool dictionaries for a solution of a > problem at hand: I need to collect some information (warnings, errors, and > reports) over lots of related and unrelated classes. > > Then create a class > MyRessources and define class methods and you are done. No need to > use SharedPool + initialize + poolDictionary.... > > > For the moment I have parameters, but that is getting inconvenient with > a growing number of things to collect... > > So, if you need something it should be there and not necessarily > obscured and hidden! > > Come on, do you know in EBNF the * notation zero or more or > optional?. > You do not write your method using all the constructs of your > language, don't you? so this is the same for class definition. > > >>> So, a -1 for this change from my side. > >> > >> We just need a full class template menu item. > > Yes, but it's not there yet but this change already took away some power > without giving me back something in exchange! > > since you are an experienced programmer this is simple. Look for trait > template and send a fix to get an extra menu. > I will go to sleep now but I guess that I can do that in 10 min and we are > talking about making our system more accesssible to people. > > > I am able to ignore some parts of class creation message easily (I also > don't use class variables that often) and I don't see why students > > shouldn't be able, too. > > When is the last time you learn a new language for real? I started > Python recently because I need some fresh air :) > and I could define a class in 3 4 lines within 5 min. > Without needing class var, static, delegator... (and if you know > python you know that it can be UGLY and COMPLEX) > I found blogs of people explaining wrongs some advanced features > still many people are able to define a class > within the 10 min they started to learn python. > > > Quite contrary I think if you hide these things from students they won't > see it, won't get curious and in the end will only > > learn the boring parts of Smalltalk... > > You are wrong and you can trust me on that. > We want to make sure that people can build fast great stuff and > feel good and powerful and not > good because they succeeded to jump over the barriers in the > middle of the way. > Pharo is not an obstacle run, it should be smooth and great. > > Pharo is not for pedandic programmers or smalltalk bigots, it is > for making people been able to build things nicely. > Simplicity, simplicity, this is why one challenge for Slot is to > enable super users without breaking simplicity. > > > > Stef > > > > > > > -- best, Eliot

Feb. 3, 2014