- Pharo-dev - lists.pharo.org

[Pharo-project] Default encoding for Linux VM [WAS] Re: [For Testing] RC3 One-Click

by Mariano Martinez Peck

On Sat, Apr 3, 2010 at 1:10 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Hi Marcus. I have been testing a little the one click image and I found the > following things: > > - splash.bmp says release candidate 2. It should be release stable 1.0 or > RC3. > > - There is the __MACOSX folder...should be remove. Remember yemuzip ;) > > - In Linux VM, you pass the parameter -encoding latin1 to the VM. > Shouldn't this be UTF-8 ? I don't know. > > Several months ago, I reported this "problem". Today I saw this issue: http://code.google.com/p/pharo/issues/detail?id=3205 so....should we change to UTF-8 ?? cheers Mariano > - In /Contents/Resources not only is PharoV10.sources but also > SqueakV39.sources. Shouldn't SqueakV39.sources be deleted ? even more it > size 16MB!! > > - The name of the zip of the 1.0 maybe should have a name different > than:Pharo-1.0-10515-rc3dev.zip, for example Pharo-1.0-OneClick. > Notice the OneClick as part of the name > > - In linux there are 2 failing test: > TestIdenting >> testNewLineLeaveSpacesOnOldLine > TestIdenting >> testCR2 > They are not new. I even try to ask help and Laurent too some time ago. I > would like someone to analyze them. If it is a problem of the test, I would > remove them. If there is nothing wrong with the test, I would try to analyze > how to fix it. > > - There is a problem in the tests of RBInternalSpellChecker in Linux and > Windows, when you are not connected to internet. There are 13 errors tests. > The SpellChecker uses the MacOS library, but for Linux and Windows it uses > its own. But...it needs to download the file. Thus, it fails if you are > off-line. The place is in > RBInternalSpellChecker >> downloadData > And of course, self url is ' > http://www.lukas-renggli.ch/smalltalk/rb-spelling.dat'. > As now with Metacello configurations, it is easy to select if you want to > download the tests or not, I would put that file somehow in the image (part > of the test package). The file is 2.1 MB on disk. > But maybe there is a reason not to do this. Lukas ? > > > Cheers > > Mariano > > > > On Fri, Apr 2, 2010 at 11:53 PM, Chris Kassopulo <ckasso(a)sprynet.com>wrote: > >> On Fri, 02 Apr 2010 09:04:58 -0400, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >> >>> Here is a one-click image (for easy starting for newbies). >>> >>> I only tested this under macos, so it needs a testrun on Linux and >>> Windows >>> >>> >>> https://gforge.inria.fr/frs/download.php/26774/Pharo-1.0-10515-rc3dev.zip >>> >>> >> Ubuntu 9.04 >> >> 9177 run, 9155 passes, 20 expected failures, 2 failures, 0 errors, 0 >> unexpected passes >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

March 18, 2011

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

by pharo＠googlecode.com

Comment #2 on issue 3754 by thereluc...(a)fastmail.fm: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 i add a screenshot. Attachments: extra_scrollbar.png 47.6 KB

March 18, 2011

[Pharo-project] [call for help] Bugtracker

by Marcus Denker

There is a bug tracker at http://code.google.com/p/pharo/issues/list With currently 524 open bug reports. With 1.2Core now being released, it would help *a lot* if people who submitted a report would check that report in the loght of a released 1.2 and an actively developing 1.3... -> Has the bug already been fixed? Reports that are already fixed are just incredible wasteful. -> Does the submitted code need to be updated for 1.3? -> Did someone ask a question in the meantime? -> after a long discussion, wouldn't a sumary help to understand what the next action is? *A lot* of the reports could really need some love from the person who submitted it orginally. We should really think about some scheme to auto-close bug reports. E.g. if someone asks a question and the original submitter thinks that it's not even worth to anwer "I don't know", then a bug report should be closed after some generous amount of time (e.g. 6 Months), as it's definitly not important. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 18, 2011

Re: [Pharo-project] Issue 3205 in pharo: monticello's error on Linux

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3205 by marcus.d...(a)gmail.com: monticello's error on Linux http://code.google.com/p/pharo/issues/detail?id=3205 (No comment was entered for this change.)

March 18, 2011

Re: [Pharo-project] Issue 3575 in pharo: [Failing Tests] Obsolete classes after tests

by pharo＠googlecode.com

Updates: Status: Closed Comment #11 on issue 3575 by marcus.d...(a)gmail.com: [Failing Tests] Obsolete classes after tests http://code.google.com/p/pharo/issues/detail?id=3575 (No comment was entered for this change.)

March 18, 2011

Re: [Pharo-project] Issue 1914 in pharo: Should check the comments added to packageinfo by andreas in squeak

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 1914 by marcus.d...(a)gmail.com: Should check the comments added to packageinfo by andreas in squeak http://code.google.com/p/pharo/issues/detail?id=1914 PackageInfo will be replaced by RPackage soon

March 18, 2011

Re: [Pharo-project] Issue 953 in pharo: PackageInfo could be much faster

by pharo＠googlecode.com

Updates: Status: Closed Comment #21 on issue 953 by marcus.d...(a)gmail.com: PackageInfo could be much faster http://code.google.com/p/pharo/issues/detail?id=953 PackageInfo will be replaced by RPackage soon. (In addition, this bug report was not looked at for >6 Months) Therefore I will close this entry.

March 18, 2011

Re: [Pharo-project] GSOC 2010 results

by Alexandre Bergel

+1 Alexandre On 18 Mar 2011, at 16:16, StÃ©phane Ducasse wrote: > > How to navigate them?What model? Because this is not because you have namespace that you do not get name clash. > How to use them in presence of package? What is the impact on tools? What do we want exactly? Do we want selector namespaces? > No need to answer and I have a long list. > I'm thinking about namespaces since we did classboxes and so far the anwser is not easy. > Because I would like to have late bound class name but this may imply to see if we can avoid to have mixin. > So I think that we have more urgent things to do now. > The current need is easily solved by prefixing so let us prefix. > Because what I want is to be able to reuse tests but with another Collection package and so far simple namespaces > do not solve that and the solution I know is far to big and its impacts are big too. > Stef > > On Mar 18, 2011, at 5:25 PM, Marcus Denker wrote: > >> >> On Mar 18, 2011, at 5:18 PM, Miguel CobÃ¡ wrote: >> >>> I think the "No" answer is more like "there are no current plans, >>> because nobody has pushed it" than "the namespaces implementation is >>> banned from Pharo" >> >> >> Or: Namespaces can be done so easily wrong so that oe needs to think very carefully and >> there are no braincycles left just now. >> >> At least, that's my view... and I think that the project indeed is very important, as it shows one >> solution that we can learn from... and then we can realize something for Pharo after we >> are sure we learned enough. >> >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 18, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by Lukas Renggli

>> The only refactoring that would make sense is to extract all >> senders of 'Smalltalk globals' to a separate method so that subclasses >> could override it. > > Why? > Frankly you have so absolute statements. > This is good to feel like idiots: "the only refactoring that makes sense" > > We are making ****ALL**** the tools environment aware: SystemNavigation, Compiler, > TestRunner.... so why browserEnvironment would escape to the rule? > We need that to be able to browse, compile other code than currently installed and > we will do it. > > Why having a state is a problem? Sorry but we will use this version and we will probably introduce it in core. > Because we want to have all the tool chain been able to work on a given environment. You clearly break the following methods and potentially all 55 references to BrowserEnvironment: - BrowserEnvironment>>#copyEmpty - BrowserEnvironment>>#& - BrowserEnvironment>>#I - BrowserEnvironment>>#not - BrowserEnvironment>>#isSystem - ClassEnvironment>>#classesDo: - SelectorEnvironment>>#classesDo: Not sure how you are going to meaningfully fix these when BrowserEnvironment can point to different environments? I can only repeat myself: BrowserEnvironment encapsulates the complete system (world). All that you can potentially see within a given image at a given time. If you have Pharo 1.2 and Pharo 1.3 in your image then BrowserEnvironment would enumerate Object from Pharo 1.2 and Object from Pharo 1.3. > Now if you do not like our changes we will fork. This is sad because we tried to make sure that > RB could work on them but there is no problem we can fork also RB. Just let us know. I don't know why you get angry? I am just telling you how John Brant and Don Roberts implemented the system. Just fundamentally changing core classes of a framework without understanding the implications doesn't help. If you don't believe me ask John or compare the code with the one in VisualWorks where you could actually have different system versions at the same time in the image. So again: If you want a view onto your namespace create a BrowserEnvironmentWrapper subclass that holds a reference to your namespace like PackageEnvironment with its package. That is how it is ment to be done. Lukas -- Lukas Renggli www.lukas-renggli.ch

March 18, 2011

[Pharo-project] need your attention: Package

by StÃ©phane Ducasse

Hi guys we need to think about package: right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted. - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories. Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching. So if you have suggestion please talk now. Stef

March 18, 2011