Re: [Pharo-dev] Pharo3 issues
Marcus wrote: On 31 Dec 2013, at 11:58, Tudor Girba [hidden email] wrote: I think this should not be a global preference at all. Most of the time, you actually want to commit in the same repository where you always do. Only from time to time do you need to switch and copy to another repo. So, the preference should be per browser, not global. consider that the issue was open since July. How likely is it that what you describe will ever be done? Oh, I'm quite positive. I took a look at the code in 30664. Changing view preference is already in the right-click menu on the repositories, and it is global. I *never* found it there before. Though it has something to do with repositories, putting it in the repositories menu is not helpful, as its context is not a single repository. The same problem exists with the package side, the sort methods don't belong in the context menu of individual packages. I'd suggest adding a dropdown-menu on a button in the searchfield-row for both the packages and the repositories, allowing the setting of all-package and all-repository properties. And of course removing the preference and moving it to the instance side. Stephan
Re: [Pharo-dev] towards moose in the pharo ide (gtinspector / gtdebugger)
Hi Doru, I like very much how easy it is to modify and adapt these tools. The higher abstraction level provided by Glamour really pays off here. In the past week I also looked at Nautilus, MCWorkingCopyBrowser and the UiDesigner and the difference is shocking. Stephan
Re: [Pharo-dev] Pharo3 issues
Sean wrote: I would've fixed it already, but since someone went through the trouble to add a setting, I figured maybe there was a use case I was missing... Please go ahead, I won't have any more time to do it today or tomorrow. Design, no choice! Stephan
Re: [Pharo-dev] UDP Broadcast message
Norbert wrote: To send or receive a broadcast packet you need to put special options on the socket on the native side (setsockopt). You need to look if the SO_BROADCAST option is mentioned anywhere. If not it won’t work without adding them. And for sending them you need almost special privileges on the system. This is not a „user feature“. And even though it is the right thing for lots of situations, your network is also very likely to not do the right thing with broadcast packets. Etsy decided on using bittorrent protocol to update their production servers indexes, because they found it too difficult to get their network to do the right thing. They found that their switches were basically livelocked while dealing with broadcast packets. http://codeascraft.com/2012/01/23/solr-bittorrent-index-replication/ If you want the broadcast to travel a little further, the routers need to be configured not to drop the packets. Stephan
Re: [Pharo-dev] Which tests should be run in CI?
Stef wrote: Doru wrote: We need to reconsider how we approach continuous integration for pharo-based images. can you expand ? The most important thing, from my POV, is to not break things silently when cleaning up the system. Having a system integration test that tells you you are no longer supposed to have packages methods, makes things easier to fix. Should we tag tests with integration to make clear what tests are expected to be run in the 'leaf' builds? Marcus wrote: But *Grease* still is the problem: in the tradition of the wonderful philosophy “Lets keep all smalltalk crappy and provide some layer on top”, it redefines #package and therefore requires that no Smalltalk ever implements #packages on the class side to return the system concept of package. That's not a really helpful remark. The purpose of Grease is to provide a compatibility layer to let a.o. Seaside and Magritte work on as many Smalltalks as possible. In 2009, using a class-side packages method in GRPackage was not a bad idea, AFAIK. The name was not claimed, and later used by several other classes. By not having a test claiming the use of packages for RPackage, (and you might ask, why not rPackages?), and having lots of old flag: #todo code in RPackage, it is not easy for Grease maintainers to find out that that renaming is the obvious thing to do. It is part of the Grease API, and making changes there always involves checking all platforms. AFAIK, no maintainer has regular access to all platforms. Stephan
Re: [Pharo-dev] Which tests should be run in CI?
Doru wrote: This is clearly an issue of Grease. And it is not essential either as there are no senders to it. There are senders in Seaside. They look not so difficult to change. So, I see no reason not to rename it in Grease. It is a compatibility layer, so you wouldn't be able to know looking only from Pharo. Stephan
[Pharo-dev] Which tests should be run in CI?
I notice that several builds are green, though I added a breaking test to Pharo 3. That probably means that those builds don't run all of the Pharo tests. Most builds probably don't need to run all tests (all the time), but it might be useful to be able to mark tests as integration tests, that are expected to be run by all downstream builds. Concrete, every Pharo 3 build that loads Grease should currently be red. Stephan
Re: [Pharo-dev] Which tests should be run in CI?
Torsten, For unit tests building on green builds might be enough, but what about integration/smoke tests? Concrete case: I added a test to check that no class implements packages That is a test that should be run by all builds, but is not. The consequence is that Moose and Pharo3 based builds using seaside or magritte can not reliably use senders of I assume there are more tests like this. Stephan
Re: [Pharo-dev] Issue for Pharo2 needs review
Downloaded 20628 288 VM, run on a Mavericks mac Browse the slice: Segmentation fault Mon Dec 9 10:12:26 2013 https://github.com/pharo-project/pharo-vm.git Commit: 71adca113a9aff2876288927e5c1c86bf7ac13e2 Date: 2013-12-07 05:00:47 -0800 By: Philippe Back philippeb...@gmail.com Jenkins build #14776 C stack backtrace: 0 Pharo 0x0019fdac reportStackState + 140 1 libsystem_platform.dylib0x9b433deb _sigtramp + 43 2 ??? 0x 0x0 + 4294967295 Smalltalk stack dump: 0xbffb64e0 M DisplayScreenforceToScreen: 0x1f5031f4: a(n) DisplayScreen 0xbffb64fc M [] in DisplayScreenforceDamageToScreen: 0x1f5031f4: a(n) DisplayScreen
Re: [Pharo-dev] Issue for Pharo2 needs review
Hmm, not easily reproducible. Stephan
Re: [Pharo-dev] Committing slices to Pharo30Inbox still doesn't work for me
I found a workaround. See https://pharo.fogbugz.com/f/cases/12379/Shape-is-missing-a-comment For me, the Nautilus create a slice and commit” doesn’t work. Creating the slice from the monticello browser and saving it there does work.
Re: [Pharo-dev] Committing slices to Pharo30Inbox still doesn't work for me
And a new version of the 12324 slice is committed
[Pharo-dev] Bogus validation report
https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/4185//artifact/validationReport.html
Re: [Pharo-dev] Responsible development
Stef wrote Now for example you can load code in a background process now if you modify objects that may be impacted by changes then you can get in trouble. Here is a live example of doing that: This is how we load Delphi code in Moose. http://www.flickr.com/photos/35787002@N03/10609428345/ In the background. That is very nice when it works. But not so nice when the background process keeps on popping up debuggers. Lots of debuggers. So many, that it gets difficult to get access to the process browser to kill the loading process. As long as the proces ends and you don’t run out of memory, you can then kill all open debuggers with some code like World submorphs select: [:each | (each respondsTo: #label) ifTrue: [each label beginsWith: 'Message’] ifFalse: [ false] ] thenDo: [:each | each close] And then you wait a few minutes for the debuggers to be closed. Ben wrote I will do an experiment and fork each Nautilus opening to see if it can save my ass :P Background processing only works in a very specific setup. This won’t work when every nautilus browsers just runs in its own thread, as nearly all code in Pharo is not thraad-safe. Is the compiler reentrant? Or even woorse, is committing packages reentrant? I was saying that theoretically it should not freeze the UI thread if you fork. How are you going to find the one thread that does something wrong and freezes the UI? Stephan
Re: [Pharo-dev] Query STHub from outside
Hi Torsten, Just take a look at: http://smalltalkhub.com/mc/StephanEggermont/DeprecationFinder/main It is deliberately rate-limited. It doesn’t find the teams and their projects. The API you can find by downloading the SmalltalkHub image from ci. That wants a MongoDB running with default ports Stephan
Re: [Pharo-dev] Review someone
Just tried in 30624. Looks good to me. Works a lot faster. Is not trivial to load by hand, it needs search strings entered (nil isn’t empty) The way the search is forked doesn’t interfere with the UI thread? Stephan
Re: [Pharo-dev] Review someone
Would it make sense to check the search string for complex strings (*\?) and switch to regex searching then? That should be a simple extension (later). Stephan
Re: [Pharo-dev] help about codeImporter
Ben wrote: who put a ô in the code at the first place ? :P Doesn’t happen often, I’m happy to observe. Strings in code with interesting characters are a much more common problem, though. Made it impossible to import MCs into Gemstone. Stephan
Re: [Pharo-dev] Review someone
I managed to break it. Open monticello, open the 30inbox type sl return backspace backspace return Still needs a nil check it seems Stephan
Re: [Pharo-dev] Review someone
Ben wrote: It used to be regex, but regex are slow (and far slower than just string comparison) Yes, I saw that. They are also useful. Checking if the search string contains regex characters is not slow. Only doing regex checking when they are there solves the main slowness, without losing the flexibility. Stephan
[Pharo-dev] WhatsUp from: 2013-12-02 until: 2013-12-15
### Here's what I've been up to since the last WhatsUp: - put PetitDelphi in the moose ci - complained about losing code (issue 12324) - added the twitter bootstrap magritte demo to the new bootstrap code - try to understand the problems with packages - committed a fix and test for packages that will break a lot of builds ### What's next, until 2013-12-15 (*): - let QCMagritte use the new bootstrap - find out why/how I can’t commit slices to Pharo30inbox (*) we'll be expecting results by then ;)
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Esteban wrote: sorry, but I still do not understand why this is a problem. can you elaborate why it should not be more implementations? It breaks the system. You can no longer use senders. So currently, all Moose and Seaside based 3.0 images are somewhat unusable. Stephan
Re: [Pharo-dev] Slice 12324
I tried committing/copying an updated slice, but am unable to get it into the Pharo30Inbox, even though I can copy packages in it. Is this a known issue? Stephan
Re: [Pharo-dev] [ANN] Roassal 3d
Nice! I directly tried it loading into 30618 with te latest vm on OS X Mavericks. When loading the configuration as shown in the manual, there was a complaint about a class not found yet. The examples showed up fine though. They look great. The first one with the square/cube I couldn’t get the camera viewpoint to move to where I could see it was a cube. That worked much better with the later examples. The session management isn’t working out well: saving the image with an open view and quitting, the image crashed on restart. I’m looking forward to adding some 3D views to PetitDelphi. Stephan
[Pharo-dev] Committing slices to Pharo30Inbox still doesn't work for me
Here’s a new slice, the corresponding packages are in the inbox. SLICE-Issue-12324-There-should-be-no-class-side-implementations-of-packages-except-for-ClassDescription-StephanEggermont.2.mcz Description: Binary data
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Mariano wrote: You will only have problems with class side #packages. Are all those 35 class side? 5 out of 35. 4 of which are in Pharo 3 Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Stef wrote: The real problem is that a CLASS now responds to the packages message. SUnitAPIDocumentation also implements packages class-side. If I try to add a instance side method #bla I get a debugger (but the method is added). Searching for implementors then also returns a debugger. I assume this problem wasn’t seen as the classes implementing packages class-side don’t have instance side behavior. The classes implementing packages class-side are SUnitAPIDocumentation AnnouncementsAPIDocumentation HelpAPIDocumentation ProfStefAPIHelp They all return an array of package name strings Stephan
Re: [Pharo-dev] Grease conflicts #packages with RPackage
I could copy the separate packages, but not the slice. Please note that the added test is expected to fail on all builds containing Grease-Core. Stephan
Re: [Pharo-dev] Versionner Impressions
Hi Sean, Didi you compare it to Metaceller in Moose? Stephan
[Pharo-dev] Smalltalkhub ci image
The smalltalkhub build has been red for quite some time now. If I want to run a hub, should I take the latest build? Stephan
[Pharo-dev] Slice 12324
Can anyone put it in place? Can’t seem to commit it
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Stef wrote: Do you think that if an external library redefines the semantics of #class, it will be a Pharo bug? I don’t know. I know I have 35 implementers of #packages in my Moose image, and 191 senders. And I know that in Magritte 3 we changed from using #description to #magritteDescription to avoid polluting the namespace with a word that is commonly used for other things. At the same time I don’t exactly enjoy adding prefixes everywhere. DeprecationFinder tells me there are 60 projects on smalltalkhub using #packages. And I know I have to be careful about where I use #name. And when taking a look at the problem, I immediately run into lots of methods flagged #todo, a.o. (CompiledMethodpackageFromOrganizer:) that seems to suggest a different solution. I can imagine a more effective way of convincing Grease maintainers that they should switch API :) Stephan
Re: [Pharo-dev] Nautilus no longer guards against changed methods
Chris wrote: Sean wrote: In general in UIs, he best approach is to do what the user requests without hesitation, and make everything undoable. Ah, thanks for saying that. People need to be reminded. I think the tablet craze has lurched the world back into modal UI's being ok”. I don’t find modal UI’s ok, but this non-modal UIs is worse. It is a mess that is not going to get better by patching up and needs to be reverted. Stephan
[Pharo-dev] Correction for XML-Writer
The configuration of XMLWriter refers to the wrong repository. That breaks the moose build. I don’t seem to have commit rights to PharoExtras, so ConfigurationOfXMLWriter-StephanEggermont.41.mcz Description: Binary data
Re: [Pharo-dev] Old ClassBuilder remove!
Nice! kilon wrote: any links why newcomers like me should be impressed ? Whats the advantages ? Then we can now have more compact versions of FreeTypeSettings LabelMorph MorphTreeNodeMorph MorphTreeListManager ThemeSettings MultistateButtonMorph PharoUserPermissions SimpleHierarchicalListMorph Nautilus class SpecTreeColumn PluggableIconListMorph MorphTreeMorph Workspace CompositionScanner Paragraph MethodOveridesAction HandMorph TextComposer ScrollBar NECContext MultiByteFileStream NewValueHolder DynamicClassGroup SearchMorph NautilusHistoryEntry PluggableTextFieldMorph PluggableListMorph TableLayoutProperties DynamicGroup DropListMorph GradientFillStyle PackageTreeNautilus PluggableTextMorphWithLimits NECUntypedModel BalloonEngine MetacelloPharo30Platform SystemWindow NautilusWindow NECPreferences class EditorFindReplaceDialogWindow GoBackStringMorph NautilusHistoryEntryWithSourceCode MCCacheRepository PluggableButtonMorph AlphaImageMorph PluggableTextMorph RxMatcher MorphExtension TextMorphForFieldView MorphTreeColumn FindReplaceService CheckboxMorph TextMorphForEditView IndentingListItemMorph ControlButtonMorph CheckboxButtonMorph with multiple booleans mapped to one instVar |set| set := IdentitySet new. Object allSubclasses do: [ :aClass | |varSize coll nr candidate | candidate := false. varSize := aClass instSize. coll := aClass allInstances. nr := 10 min: coll size. (coll first: nr) do: [ :anInstance | |value nrBoolean| nrBoolean := 0. 1 to: varSize do: [ :varIndex | value := anInstance instVarAt: varIndex. value class = True ifTrue: [ nrBoolean := nrBoolean + 1 ]. value class = False ifTrue: [ nrBoolean := nrBoolean + 1 ]]. nrBoolean 1 ifTrue: [ candidate := true ] ]. candidate ifTrue: [ set add: aClass ]]. set.
Re: [Pharo-dev] Old ClassBuilder remove!
Camillo wrote: I love these scripts :P.. maybe you should make gists [1] out of them :) Good idea https://gist.github.com/StephanEggermont/7598946
Re: [Pharo-dev] Old ClassBuilder remove!
Nicolas wrote: It has to be more simple than that… Probably. I don’t do this often enough. Why not searching for allReferences to true and false, and gather the class of referents? How is that going to give me the values of the instVars? This would also remove the limitation of first 10 instances… Taking a look at all instances just takes a bit longer... I’m open to suggestions. Stephan
Re: [Pharo-dev] GraphViz - renggli repo down
hernan/BioSmalltalk Is what DeprecationFinder me tells Stephan Verstuurd vanaf mijn iPhone
Re: [Pharo-dev] GraphViz - renggli repo down
I have for you GraphViz-hfm.46.mcz GraphViz-jrp.42.mcz GraphViz-jrp.41.mcz As soon as my ADSL is up again. The first is on smalltalkhub, btw Stephan Verstuurd vanaf mijn iPhone
Re: [Pharo-dev] help needed with fixing the SpecDebugger
Doru wrote: I need a bit of help with the issue of the SpecDebugger relying on the default inspector being implemented in Spec. Hmm, one gets used to having a decent inspector. Going back to the Pharo 3 default is not funny… The GTInspector might be a bit of an ugly duckling, but there really is a big bad-ass powerful swan in there. I strongly support the help request. And phd organization of course. Stephan
Re: [Pharo-dev] i18n - Where to start?
With the QCMagritte image (from the pharo contributions ci). That has build-in support for translations. Just start it and open the web demo Stephan
Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic
How could we recognize the using of a deprecated stream? With a tool like DeprecationFinder it should be easy to walk the repositories and find out where they are used. Stephan
Re: [Pharo-dev] Deep Into Pharo: PPExpressionParser
Norbert wrote: You may have a look at PParser#delimitedBy: Thank you. Stephan
Re: [Pharo-dev] Deep Into Pharo: PPExpressionParser
Hi Sean, In PetitDelphi, we defined a few convenience methods like plusFor:separatedByToken: that you might find useful. Stephan
Re: [Pharo-dev] WhatsUp from: 2013-11-04 until: 2013-11-17
Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: Put out CFP for FOSDEM2014 devroom Lots of improvements to PetitDelphi http://www.flickr.com/photos/35787002@N03/sets/72157634356004836/ First step in making QCMagritte use new Bootstrap ### What's next, until 2013-11-17 (*): Handling of compiler directives for PetitDelphi, first ifdefs and includes Still a lot of parse errors to fix Diego Stephan
[Pharo-dev] Github mails
I’d strongly prefer auto-generated mails to be moved to the issue tracker list. Anything that doesn’t have decent subjects has no place in this mailing list [pharo-project/pharo-core] is no decent subject, and neither is [pharo-project/pharo-core] 612dc4: 30542 Stephan Eggermont
Re: [Pharo-dev] SmalltalkHub red
SmalltalkHub uses Seaside 3.0.8, referring to an old version of Grease. Upgrading to a newer Seaside should solve that problem, AFAIK Stephan
[Pharo-dev] Smalltalkhub commit dates broken?
Commit dates seem to be wrong. I committed a few packages in Moose/PetitDelphi today, and find them back as 17/05/2013 Stephan
Re: [Pharo-dev] Smalltalkhub commit dates broken?
Nico wrote: The creation of the MC packages are from today too? Name: PetitDelphi-StephanEggermont.129 Author: StephanEggermont Time: 24 October 2013, 3:54:21.159 pm UUID: b310f98a-41cf-4dd6-8be4-d1954ae69e4b Ancestors: PetitDelphi-StephanEggermont.128 Moved some AST classes
Re: [Pharo-dev] failing moose tests
(from pharo -dev) PharoVM-AcceptanceTest loads Moose-Stable. That is based on a snapshot. As the snapshot flattens the configuration, it is basically unpatchable. Stephan
Re: [Pharo-dev] failing moose tests
Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery15Days 64 ms 3 Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery2Years 52 ms 3 Moose.Test.HismoImporter.MooseHismoImporterTest.testEvery6Months51 ms 3 Don't know where they come from. The implementation should be using everyNDays/Months/Years AFAIK Stephan
Re: [Pharo-dev] failing moose tests
There has been a fixed package on smalltalkhub since 10 days, so it looks like a configuration problem Name: Moose-Test-HismoImporter-StephanEggermont.5 Author: StephanEggermont Time: 20 September 2013, 2:45:53.012 pm UUID: 766c5b47-daa6-4b51-af8f-091539186c59 Ancestors: Moose-Test-HismoImporter-AndreHora.4 Fixed some tests
Re: [Pharo-dev] Smalltalkhub - REST API :) (a.k.a. Sorry, if I broke it...^^)
Hi Marcel, my goal is to find the big ones to take a closer look at. Thus, next steps would be to fetch the latest MCZ of all projects and then analyze their contents. :) That is in DeprecationFinder. (load in a Moose 4.8 after loading NeoJSon). Current analysis is just getting the invocations from a MooseMonticelloImporter for the latest packageversion. It needs to be extended to also walk the team projects. Further steps would be to make it incremental and have a fuel file as artefact in a Jenkins build. Stephan
Re: [Pharo-dev] Smalltalkhub - REST API :) (a.k.a. Sorry, if I broke it...^^)
And please don't all at the same time download and run the DeprecationFinder code, until Nicolas tells you he wants to do a load test! Stephan
Re: [Pharo-dev] Use pharo users mailing list
Yes, it is dead. The number of answers is getting lower and lower, the questions get more and more detailed. http://stackoverflow.com/questions/18946662/if-pypy-is-6-3-times-faster-than-cpython-why-not-just-use-faster-interpreter Hmm yes, that is a question that needs to be closed. Interesting, but not allowed. That's the difference between a large and a small language. Or rather, it is just arbitrary. Stephan
Re: [Pharo-dev] Use pharo users mailing list
Kilon wrote: Excuse me I have just an allergy in the word dead so I could not resist. I remember for 3 days in a row there was some people popping in #smalltalk irc channel asking , why smalltalk is dead, how dead it is, why the corpse still smells and what the autopsy revealed :D. I find people ... hilarious. That's my disappointment speaking. It was a great idea. I'm an early stackoverflow user with 10K+ reputation. The first year it was pretty good, but I've seen it rapidly detoriate to the level where looking at random new questions doesn't make sense anymore. The result of that is that there is no longer the cross-pollination that made stackoverflow an interesting site. Stephan
Re: [Pharo-dev] Use pharo users mailing list
Hannes wrote: In reply to this post by Stephan Eggermont On 9/23/13, Stephan Eggermont [hidden email] wrote: Kilon wrote Here is a radical suggestion you probably don't want to hear. Close down Pharo users mailing list, redirect everyone to stackoverflow. Definitely not. Stackoverflow is nearly dead, and seriously unsuitable for small languages. There are obstacles but one cannot say that it is seriously unsuitable. I feel fully qualified to make that statement. Getting voted on by majority views is not exactly what we need. Especially not in a cargo-cult driven profession. Good questions will get closed by clueless people. Mostly if the form does not fit. Nope. there has been a strong change in what is deemed to be an acceptable question on SO in the past years. And not in the right direction. I know several posters here who have been bitten by that. And if there are Pharo people (maybe earned in another area) with enough reputation points this may be prevented That would be nice, but isn't the case. Stackoverflow doesn't work like that. Good answers will get downvoted because they go against majority views. Why? Because stackoverflow is an opinion site, dominated by popularity. Nobody says an answer has to be right. Like I said, take a look at questions on OODBs. The ranking system is heavily skewed towards popular languages. It is based on the number of hits which is naturally less in less popular languages. However subcommunities may function well in stackoverflow. No, not really. It means that members of subcommunities have less rights and power. There is no value in subdividing our community further. Stephan
[Pharo-dev] Deprecated selector #metaclass on Smalltalkhub
These projects and packageversions on Smalltalkhub use the #metaclass selector. This might refer to a deprecated selector, replaced by #theMetaClass The packageversions were selected as latest+not merged gokr/DeltaStreams System-gk.143 StephaneDucasse/ArchiveTraits TraitsUI-al.19 StephaneDucasse/ArchiveTraits TraitsUI-al.21 StephaneDucasse/ArchiveTraits TraitsUI-al.2 StephaneDucasse/ArchiveTraits System-al.55 StephaneDucasse/ArchiveTraits System-al.85 StephaneDucasse/ArchiveTraits System-al.52 StephaneDucasse/ArchiveTraits System-al.63 AnneEtien/RingJET Ring-History-Definitions-VeronicaUquillas.104 AnneEtien/RingJET Ring-Core-Kernel-MarcusDenker.90 BenjaminVanRyseghem/NemoNemo-BenjaminVanRyseghem.21 andrehora/FindBugs Refactoring-Critics-AndreHora.18 andrehora/HoraExp Moose-Tests-SmalltalkImporter-Core-AndreHora.29 andrehora/HoraExpTemp Moose-Tests-SmalltalkImporter-Core-AndreHora.30 AlainPlantec/Platypus2 Platypus2-AlainPlantec.93 CipT/TalkFFITalkFFI-SmalltalkBinding-CiprianTeodorov.16 CipT/TalkFFITalkFFI-NativeBoostBinding-CiprianTeodorov.23 CipT/TalkFFITalkFFI-NativeBoostBinding-CiprianTeodorov.4 CipT/TalkFFITalkFFI-NativeBoostBinding-CiprianTeodorov.15 Guille/Seed Seed-Basic-GuillermoPolito.8 Guille/Seed Seed-PharoCandle-GuillermoPolito.46 Guille/Seed Seed-PharoCandle-GuillermoPolito.14.6 Guille/Seed Seed-Mappings-GuillermoPolito.7 Guille/Seed Seed-Mappings-GuillermoPolito.6 Guille/Seed Seed-HazelBuilder-GuillermoPolito.197 Guille/Seed Seed-HazelBuilder-GuillermoPolito.129 Guille/Seed Seed-HazelBuilder-GuillermoPolito.125 Guille/Seed Seed-HazelBuilder-GuillermoPolito.13.127 Guille/Seed Seed-SeedLoader-GuillermoPolito.6 Guille/Seed Seed-Pharo-GuillermoPolito.10 Guille/Seed Seed-MetaLevel-GuillermoPolito.16 Guille/ObjectSpace OzObjectSpace-GuillermoPolito.33 Guille/ObjectSpace OzObjectSpace-GuillermoPolito.17 Guille/ObjectSpace AtomObjectSpace-GuillermoPolito.25 Guille/ObjectSpace Seed-MetaLevel-GuillermoPolito.16 Guille/ObjectSpace AtomAtoms-GuillermoPolito.1
[Pharo-dev] Better text needed for contributions
Track and tag your change/Fix/Enhancement: • Add an entry to the Issues tracker describing your change (include the package version name of the package). Set the status to Fixed. That doesn't work. Possible status changes are 'Working on' and 5 variations on 'Work needed'. And 11628 is fixed Stephan
Re: [Pharo-dev] Better text needed for contributions
Camille wrote: You need to click on 'resolve' instead of 'edit' I think. Ah, thank you. That works. Stephan
Re: [Pharo-dev] Smalltalkhub = 503
Yes, smalltalkhub is nice. And installing your own is very easy. I think more people should do so. It doesn't seem to be as solid as ss3, but can be installed much easier, and on legacy platforms (windows). Running your own mirror should not take that much space and capacity, and makes you less dependent on central infrastructure staying up. Stephan
[Pharo-dev] Putting load on smalltalkhub
Around 12.00 we managed to load and analyze upto 100 mczs/minute from Smalltalkhub. We hoped that we would not be able to overload Smalltalkhub from a home ADSL connection, using a single (non multi-threaded) Moose image. However, this seems to coincide with some failing jenkins builds. We apologize for any inconveniences we might have caused. What is the best way to get a copy? Or is our analysis wrong? Diego Stephan
Re: [Pharo-dev] Putting load on smalltalkhub
Igor wrote: i think you should contact Nico about how to run tests using some test server first, and only if it passes, on deployed one :) Oh, the code was working fine ;) Really no different to copying monticello packages from one repo to another. It's just that I try to find all invocations in a package before loading the next one. B.t.w. the last succesfully loaded package was VMMaker.oscog-nice.257.mcz which is 2.8 MB. So it seems smalltalkhub could benefit from load balancing. If the image is responsible for the streaming, it basically has twice as much to do as mine. Read from mongo, and write to me. Stephan
Re: [Pharo-dev] Putting load on smalltalkhub
Sven wrote StHub is an important shared community resource. Definitely. And this is a stop-the-line problem. Having a single image on an ADSL connection bring down smalltalkhub doing one mcz request at a time means there is a serious dos risk. This is my packagecache from the offending run: -rw-r--r--@ 1 stephan staff 2790645 18 sep 12:06 VMMaker.oscog-nice.257.mcz -rw-r--r--@ 1 stephan staff38268 18 sep 12:06 Manifest-CriticBrowser-AndreHora.85.mcz -rw-r--r--@ 1 stephan staff18932 18 sep 12:06 CriticRanking-RuleChecker-SimonAllier.1.mcz -rw-r--r--@ 1 stephan staff57206 18 sep 12:06 CriticRanking-SimonAllier.4.mcz -rw-r--r--@ 1 stephan staff 2468 18 sep 12:06 GT-GlamourDebugger-AndreiChis.4.mcz -rw-r--r--@ 1 stephan staff 2633 18 sep 12:06 PlaneChase-FrancoisLepan.2.mcz -rw-r--r--@ 1 stephan staff 9139 18 sep 12:06 DebuggerActions-AndreiChis.39.mcz -rw-r--r--@ 1 stephan staff 4099 18 sep 12:06 DebuggerExtensions-AndreiChis.5.mcz -rw-r--r--@ 1 stephan staff 4545 18 sep 12:06 DynamicSpec-Examples-AndreiChis.5.mcz -rw-r--r--@ 1 stephan staff13455 18 sep 12:06 PetitParserDebugger-AndreiChis.24.mcz -rw-r--r--@ 1 stephan staff 3587 18 sep 12:06 Hackathon-SATToSE2013-AndreiChis.2.mcz -rw-r--r--@ 1 stephan staff 8170 18 sep 12:06 ACD-Glamour-Interface-AndreiChis.47.mcz -rw-r--r--@ 1 stephan staff10029 18 sep 12:06 ACD-Model-AndreiChis.36.mcz -rw-r--r--@ 1 stephan staff 3451 18 sep 12:06 ACD-Tests-AndreiChis.1.mcz -rw-r--r--@ 1 stephan staff 4084 18 sep 12:06 ConfigurationOfAnnouncerCentricDebugger-AndreiChis.4.mcz -rw-r--r--@ 1 stephan staff 4071 18 sep 12:06 Moose-JEE-Tests-Importers-PHP-MichaelRuefenacht.4.mcz -rw-r--r--@ 1 stephan staff 3701 18 sep 12:06 Moose-JEE-EJBDraftObjs-FabrizioPerin.2.mcz -rw-r--r--@ 1 stephan staff 6663 18 sep 12:06 Moose-JEE-Importers-SQL-FabrizioPerin.44.mcz -rw-r--r--@ 1 stephan staff 4045 18 sep 12:06 Moose-JEE-CCProject-Importer-FabrizioPerin.15.mcz -rw-r--r--@ 1 stephan staff 887 18 sep 12:06 Moose-JEE-Tests-ConceptualSchema-FabrizioPerin.2.mcz -rw-r--r--@ 1 stephan staff16952 18 sep 12:06 Moose-JEE-Tests-Extensions-FabrizioPerin.10.mcz -rw-r--r--@ 1 stephan staff78859 18 sep 12:06 Moose-JEE-Model-FabrizioPerin.142.mcz -rw-r--r--@ 1 stephan staff44110 18 sep 12:05 Moose-JEE-Model-FabrizioPerin.24.mcz -rw-r--r--@ 1 stephan staff56592 18 sep 12:05 Moose-JEE-Model-FabrizioPerin.77.mcz -rw-r--r--@ 1 stephan staff 6750 18 sep 12:05 Moose-JEE-GitLog-Model-FabrizioPerin.20.mcz -rw-r--r--@ 1 stephan staff 9005 18 sep 12:05 Moose-JEE-Reports-FabrizioPerin.15.mcz -rw-r--r--@ 1 stephan staff 7356 18 sep 12:05 Moose-JEE-DesignPattern-FabrizioPerin.9.mcz -rw-r--r--@ 1 stephan staff 1391 18 sep 12:05 Moose-JEE-Importers-PHP-FabrizioPerin.1.mcz -rw-r--r--@ 1 stephan staff 3087 18 sep 12:05 Moose-JEE-Tests-Importers-GitLog-FabrizioPerin.6.mcz -rw-r--r--@ 1 stephan staff12506 18 sep 12:05 Moose-JEE-Importers-PHP-MichaelRuefenacht.43.mcz -rw-r--r--@ 1 stephan staff12190 18 sep 12:05 Moose-JEE-Importers-PHP-MichaelRuefenacht.36.mcz -rw-r--r--@ 1 stephan staff17316 18 sep 12:05 Moose-JEE-Wizard-FabrizioPerin.42.mcz -rw-r--r--@ 1 stephan staff 4580 18 sep 12:05 Moose-JEE-CCProject-Tests-Model-FabrizioPerin.7.mcz -rw-r--r--@ 1 stephan staff 2350 18 sep 12:05 Moose-JEE-Tests-Architecture-Model-FabrizioPerin.1.mcz -rw-r--r--@ 1 stephan staff 4099 18 sep 12:05 Moose-JEE-Tests-EJBDraftObjs-FabrizioPerin.1.mcz -rw-r--r--@ 1 stephan staff 4343 18 sep 12:05 Moose-JEE-Tests-Tiers-FabrizioPerin.7.mcz -rw-r--r--@ 1 stephan staff12994 18 sep 12:05 ConfigurationOfMooseJEE-FabrizioPerin.111.mcz -rw-r--r--@ 1 stephan staff 3040 18 sep 12:05 ConfigurationOfMooseJEE-FabrizioPerin.2.mcz -rw-r--r--@ 1 stephan staff 2347 18 sep 12:05 Moose-JEE-Tests-Core-FabrizioPerin.6.mcz -rw-r--r--@ 1 stephan staff 2055 18 sep 12:05 Moose-JEE-CCProject-Tests-Importer-FabrizioPerin.4.mcz -rw-r--r--@ 1 stephan staff 3750 18 sep 12:05 Moose-JEE-Help-FabrizioPerin.2.mcz -rw-r--r--@ 1 stephan staff57573 18 sep 12:05 Moose-JEE-Tests-Model-FabrizioPerin.1.mcz -rw-r--r--@ 1 stephan staff 4170 18 sep 12:05 Moose-JEE-Architecture-FabrizioPerin.1.mcz -rw-r--r--@ 1 stephan staff 5888 18 sep 12:05 Moose-JEE-CCProject-Tests-XMLElements-FabrizioPerin.5.mcz -rw-r--r--@ 1 stephan staff 3739 18 sep 12:05 Moose-JEE-SQL-Model-FabrizioPerin.13.mcz -rw-r--r--@ 1 stephan staff 297048 18 sep 12:05 Moose-JEE-CCProject-Tests-Resources-FabrizioPerin.2.mcz -rw-r--r--@ 1 stephan staff 3371 18 sep 12:05 Moose-JEE-CCProject-XMLElements-FabrizioPerin.8.mcz -rw-r--r--@ 1 stephan staff 4183 18 sep 12:05 Moose-JEE-JSP-Model-FabrizioPerin.5.mcz -rw-r--r--@ 1 stephan staff 6971 18 sep 12:05 Moose-JEE-CCProject-Model-FabrizioPerin.14.mcz -rw-r--r--@ 1 stephan staff 7950 18 sep
[Pharo-dev] Smalltalkhub down?
We noticed smalltalkhub is currently down. We have been generating some load, walking smalltalkhub a bit today, to see how we could get access to the latest versions of all packages. That should help us determine which projects use deprecated methods. Diego Stephan
[Pharo-dev] How to contribute updates
Found some improvements for the wiki page on fogbugz. I don't see a way to make changes myself. - refer to the smalltalkhub repositories, explain the squeaksource history; - the flow is not so clear in the difference between describing the contribution and where to put it (attachment, paste log message?) - no procedure for merging described - 'you are ready for the next step' which is? - unstable refers to Pharo20 instead of 30 - how to handle fixes for both 20 and 30 Stephan
Re: [Pharo-dev] How to contribute updates
works. But that doesn't mean that I have all the answers... Stephan
[Pharo-dev] Interesting regression on 30366
When running Pharo 30366 tests on Pharo VM 6.0-pre (21.0) on a 10.6.8 mac I get different results when I open the image and run the tests compared to when I saved and quit the image and then re-run the tests. 2nd time results: 11287 run, 11232 passes, 12 skipped, 26 expected failures, 6 failures, 23 errors, 0 unexpected passes Failures: DelayTest#testMultiProcessWaitOnSameDelay ReleaseTest#testUnknownProcesses NetNameResolverTest#testLocalHostName ProcessTest#testHighPriorityOverridesWaitTime BlockClosureTest#testTrace ReleaseTest#testObsoleteBehaviors Errors: NBPointerArgumentsTests#testEnumCase1ByteArray NBPointerArgumentsTests#testEnumCase1ExternalAddress NBPointerArgumentsTests#testEnumCase2ByteArray NBPointerArgumentsTests#testEnumCase2ExternalAddress NBPointerArgumentsTests#testEnumCase3ByteArray NBPointerArgumentsTests#testEnumCase3ExternalAddress NBPointerArgumentsTests#testEnumCase4ByteArray NBPointerArgumentsTests#testEnumCase4ExternalAddress NBPointerArgumentsTests#testIntCase1ByteArray NBPointerArgumentsTests#testIntCase1ExternalAddress NBPointerArgumentsTests#testIntCase2ByteArray NBPointerArgumentsTests#testIntCase2ExternalAddress NBPointerArgumentsTests#testIntCase3ByteArray NBPointerArgumentsTests#testIntCase3ExternalAddress NBPointerArgumentsTests#testIntCase4ByteArray NBPointerArgumentsTests#testStructCase1ByteArray NBPointerArgumentsTests#testStructCase1ExternalAddress NBPointerArgumentsTests#testStructCase2ByteArray NBPointerArgumentsTests#testStructCase2ExternalAddress NBPointerArgumentsTests#testStructCase3ByteArray NBPointerArgumentsTests#testStructCase3ExternalAddress NBPointerArgumentsTests#testStructCase4ByteArray NBPointerArgumentsTests#testStructCase4ExternalAddress
Re: [Pharo-dev] Interesting regression on 30366
Hmm, and somewhat later the image freezes
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
Doru wrote: I have a different opinion. This modality issue is not something we fix as a bug. Of course, we can put in place a patch that somehow makes it work in the current browser, but the core problem is a conceptual one. And that requires a redesign of the user interface. +1 And with the current state of technology, probably 2 interfaces. One for large screen devices and one for small screens. Igor wrote: But as to me it is quite simple feature, and in right hands (pointing at Ben ;), it can be implemented quite easily. I'd suggest doing something simpler: add an Open what you clicked on in a new browser as an extra option in the dialog. Making modeless editing work well, is anything but trivial, and our track record at cleaning up the UI still has some room for improvement http://forum.world.st/Nautilus-look-amp-feel-td4634990.html Stephan
Re: [Pharo-dev] Interesting regression on 30366
'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Sep 3 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Sep 3 2013 g...@github.com:pharo-project/pharovm.git Commit: 581a11414063fec0e53f047ca90de5e1b6d3b188 Date: 2013-08-28 15:11:08 +0200 By: GuillePolito guillermopol...@gmail.com Jenkins build #14636 ' Does it different Open test browser, run selected tests: 11287 run, 11258 passes, 12 skipped, 26 expected failures, 3 failures, 0 errors, 0 unexpected passes Failures: ReleaseTest#testUnknownProcesses NetNameResolverTest#testLocalHostName ProcessTest#testHighPriorityOverridesWaitTime Errors: After save-and-quit rerun: 11287 run, 11254 passes, 12 skipped, 26 expected failures, 7 failures, 0 errors, 0 unexpected passes Failures: DelayTest#testSemaphore ReleaseTest#testUnknownProcesses DelayTest#testMultiProcessWaitOnSameDelay NetNameResolverTest#testLocalHostName ReleaseTest#testObsoleteBehaviors ReleaseTest#testObsoleteClasses ProcessTest#testHighPriorityOverridesWaitTime Errors:
Re: [Pharo-dev] Interesting regression on 30366
Triangulating... 14636, 14632, 14620 Both older versions have problems with cleaning up after NB, all three have problems with high prio process, the newest two with localhostname blockclosures. Stephan And an even older version: 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Jul 31 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Jul 31 2013 git://gitorious.org/cogvm/blessed.git Commit: 2214cee58a5c5266b8ab2322b98471553b1b11c2 Date: 2013-07-31 15:32:06 +0200 By: Esteban Lorenzano esteba...@gmail.com Jenkins build #14620 ' 11287 run, 11257 passes, 12 skipped, 26 expected failures, 4 failures, 0 errors, 0 unexpected passes Failures: ProcessTest#testHighPriorityOverridesWaitTime ReleaseTest#testObsoleteBehaviors DelayTest#testMultiProcessWaitOnSameDelay ReleaseTest#testUnknownProcesses Errors: 11287 run, 11234 passes, 12 skipped, 26 expected failures, 4 failures, 23 errors, 0 unexpected passes Failures: DelayTest#testMultiProcessWaitOnSameDelay ReleaseTest#testObsoleteBehaviors ProcessTest#testHighPriorityOverridesWaitTime ReleaseTest#testUnknownProcesses Errors: NBPointerArgumentsTests#testEnumCase1ByteArray NBPointerArgumentsTests#testEnumCase1ExternalAddress NBPointerArgumentsTests#testEnumCase2ByteArray NBPointerArgumentsTests#testEnumCase2ExternalAddress NBPointerArgumentsTests#testEnumCase3ByteArray NBPointerArgumentsTests#testEnumCase3ExternalAddress NBPointerArgumentsTests#testEnumCase4ByteArray NBPointerArgumentsTests#testEnumCase4ExternalAddress NBPointerArgumentsTests#testIntCase1ByteArray NBPointerArgumentsTests#testIntCase1ExternalAddress NBPointerArgumentsTests#testIntCase2ByteArray NBPointerArgumentsTests#testIntCase2ExternalAddress NBPointerArgumentsTests#testIntCase3ByteArray NBPointerArgumentsTests#testIntCase3ExternalAddress NBPointerArgumentsTests#testIntCase4ByteArray NBPointerArgumentsTests#testStructCase1ByteArray NBPointerArgumentsTests#testStructCase1ExternalAddress NBPointerArgumentsTests#testStructCase2ByteArray NBPointerArgumentsTests#testStructCase2ExternalAddress NBPointerArgumentsTests#testStructCase3ByteArray NBPointerArgumentsTests#testStructCase3ExternalAddress NBPointerArgumentsTests#testStructCase4ByteArray NBPointerArgumentsTests#testStructCase4ExternalAddress
Re: [Pharo-dev] Should Job use SystemAnnouncer?
Camillo wrote: in this case it is only the instance of Job which knows the status. Thread-safeness is not an issue since the progress bar is pure approximation. The problem is not approximation. Objects are not reentrant, getting the value out of a model while it is reorganizing its datastructure is likely to give interesting and difficult to reproduce results (dividing by 0, nil-pointer exceptions). that does not work properly and inaccurately reports long running jobs, for instance when running tests. Usually tests take far less than 1 ms, in which case this scheme works perfectly. However from time to time you have 1 test that runs for a couple of seconds. If you run 5000 tests you have to run quite a few tests to get that 1% update margin, so very often the UI does not correctly report the current status. That is not a solvable problem. A progress bar depends on a value increasing from min to max. The model is responsible for making reasonable steps. Anyway, this requires quite some changes in the current ProgressBarMorph, so any other improvement until then is welcome :) I've put together a new slice in the 30 Inbox with the combined changes. Where should I put a backport for 2.0?
Re: [Pharo-dev] Should Job use SystemAnnouncer?
Stef wrote: did you notice a different between SystemAnnouncer and replacing it by another one? Yes, it made a significant difference. It did not remove enough overhead though. Jobvalue: was called over 100K times, doing that only every 100 increments helped enough. JobjobAnnouncer ^jobAnnouncer ifNil: [ jobAnnouncer := Announcer new ] Jobannounce: anAnnouncementClass | announcement | announcement := anAnnouncementClass on: self. self announcer announce: announcement. Jobannouncer ^Job jobAnnouncer SystemProgressMorphenable Job jobAnnouncer on: JobStart send: #startJob: to: self. Job jobAnnouncer on: JobEnd send: #endJob: to: self. Job jobAnnouncer on: JobChange send: #updateJob: to: self. SystemProgressMorphdisable Job jobAnnouncer unsubscribe: self. Morphic-StephanEggermont.1375.mcz Kernel-StephanEggermont.1351.mcz
Re: [Pharo-dev] Should Job use SystemAnnouncer?
And for 3.0 Issue 11520 Kernel-StephanEggermont.1588.mcz Morphic-Base-StephanEggermont.85.mcz
[Pharo-dev] Should Job use SystemAnnouncer?
While profiling some progressbar code, I noticed Job uses the SystemAnnouncer. It seems odd that an Announcer used for noticing code changes is reused for something unrelated to code changes. Could we have a separate announcer for this? Stephan
Re: [Pharo-dev] method vs. selector consistency?
Stef wrote: So I would like to rename them accordingly. What do you think? +1 I love consistent naming. And I'd love a list of packages on squeaksource, ss3 and smalltalkhub using these selectors in their latest version. Stephan
Re: [Pharo-dev] Rubrik, scroll to end?
In my experience, top and bottom are terminology from the visible domain, not from the contents. That could confuse users. In a non-wrapped text, is there going to be a scroll to top left and bottom right, or rather to the beginning of the first/last line? Or as it is now, ignoring the horizontal position? Stephan
Re: [Pharo-dev] Rubrik, scroll to end?
Alain wrote: Maybe something like: #scrollToEndOfText, #scrollToBeginningOfText, #scrollToEndOfLine, #scrollToBeginningOfLine. #pageUp, #pageDown, #pageLeft, #pageRight. Clear to me, thank you Stephan
Re: [Pharo-dev] WhatsUp from: 2013-08-19 until: 2013-08-31
### Here's what I've been up to since the last WhatsUp: - Deployed a pier site www.legacycode.nl on DigitalOcean - Made sure pier can be loaded cleanly in Pharo2.0 (mostly Diego's work) - And Pier kernels can be loaded and saved as code, so Sven's tutorial on deploying your first Pharo web site can also work with Pier ### What's next, until 2013-08-31 (*): - preparing esug presentations with Diego - prepare pier documentation on deploying a pier site with nginx on digitalocean - find out if it is easy to get Torch running on Pharo 3 Stephan
Re: [Pharo-dev] I would prefer to see the diff from Smalltalkhub than Git commits
Camillo wrote: - they are auto generate, no manual intervention needed to send them So they should go to the issue tracker list - the github repository is the place where you go to find changes, it's simply impossible to figure out when something broke on smalltalkhub since you cannot compare multiple packages over multiple times Sounds like it's time to migrate Torch. Stephan
[Pharo-dev] Why the github messages?
Why is github writing messages to this list (instead of the issue tracker list)? Stephan
[Pharo-dev] Drag-and-drop behavior with multiple selection
When trying to categorize multiple methods in Nautilus, I noticed behavior different from that what I expected. I click-selected one method, then shift-clicked several more. When I then did a mouse-down on the last selected and started dragging, only the last selected was dragged. The other methods were deselected. I could make the dragging of multiple elements work by directly starting dragging without having a mouse-up in between. Is this the usual behavior on another platform (than mac or windows), or should I create an issue? Noticed in a Moose 4.8, verified in 30336 Stephan
Re: [Pharo-dev] [DOC] Building and deploying your first web app with Pharo
Too bad digital ocean doesn't allow the creation of droplets at the moment. AMS and NYC are over capacity, only SF. That's no option from Europe due to latency. Stephan
Re: [Pharo-dev] My Del key not works anymore
Igor wrote: can i have it back, I haven't had a Del key on my Macs since 1990 or so. Fn Backspace to delete (US Intl) works for me. What keyboard layout do you use? Stephan
Re: [Pharo-dev] about WidgetAbstractWrapper
Can it be named, please ;) Stephan
Re: [Pharo-dev] We did it! SlotClassBuilder is active
Great! Time to simplify Magritte. Stephan
Re: [Pharo-dev] question about UI
Depending on your actual needs, you might get a much faster start by using Glamour. It allows building an application at a higher abstraction level. Stephan
Re: [Pharo-dev] Sunburst visualization
Sunburst + Roassal3D = Burning Man style CodeCity? Looking good Peace! Stephan
Re: [Pharo-dev] Roassal 3d is on its way
Erwan wrote: My question is, why trying to make something which is already working ? I mean, just changing some SourceCity stuff and it will work for roassal (i guess). SourceCity is a fixed layout with buildings blocks. Roassal allows switching combining layouts. So yes, you should be able to do a codecity layout with Roassal 3D Stephan
Re: [Pharo-dev] How do can we set up a crowdsourcing for pharo
Esteban wrote: 512 GB is reasonable maximum for a single threaded app? Certainly it is reasonable high! :-) Engineering is about trade-offs. 10K euro's: ram, or engineering time. Altough I think 4GB might be small, for me it is better to think about scaling out, instead of up. Latency bandwidth are no solved problems, AFAIK. As long as we connect images through HTTP, the amount of copying involved is going to seriously affect scalability. There is a reason Gemstone uses shared pages Stephan
Re: [Pharo-dev] Better Interruption in 2.0
Thierry wrote: UserInterruptHandler allInstances first setInterruptKeyValue: $. asciiValue Ok, that helps. In (a copy of) my PetitDelphi development image, it works. After interrupting, it also gave a low-space warning. if I let it run without interrupting, it just crashes. But that is another issue. Stephan
Re: [Pharo-dev] WhatsUp from: 2013-07-01 until: 2013-07-14
### Here's what I've been up to since the last WhatsUp: - Made some progress with Diego parsing Delphi code with PetitDelphi, units, classes, methods http://farm6.staticflickr.com/5539/9148484341_0405d8a261_o.png http://farm3.staticflickr.com/2829/9148515659_788742e646_o.png and forms http://farm4.staticflickr.com/3723/9184232826_fff1e2cffc_o.png - ran out of memory a few times uninterruptibly, so took a look at 10569 ### What's next, until 2013-07-14 (*): Parsing more of Delphi Help release Moose 4.8 Help Dusty with LightHouse issue tracker
Re: [Pharo-dev] Sprint tomorrow
Is 10569 on the list for today? Cheers, Stephan
Re: [Pharo-dev] How do can we set up a crowdsourcing for pharo
Kilon wrote: I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier. Why? It takes me less than 20 minutes to run out of available ram now, even though my machine has 8 times more. On current hardware, 512GB is a more reasonable maximum size for a single app. Pharo apps have needed more than 4GB for as long as Pharo exists, nearly all Moose applications are strongly limited by it. Philippe wrote: Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to me. Not to me. They force me to spend time thinking about partitioning at the moment I don't want to. Current machines support more than 4G/core, so 64 bits flat is needed anyhow. Later binding, I want later binding! And Objects Spaces too. They seem like a good idea. But later :) The java GC situation is ridiculous, and only exists because Oracle wants to sell databases. Stephan
[Pharo-dev] Better Interruption in 2.0
10569 Backport 2.0 Better Interruption says Work Needed. What should I look into? I am now loosing hours parsing/building large FAMIX models. Stephan
Re: [Pharo-dev] Better Interruption in 2.0
Using Henry's processToInterrupt Look for best candidate to interrupt: - any scheduled non-finalization process of lower priority - the weak-finalization process, if scheduled - the UI process Never interrupt the idle process, since killing it is fatal | fallback | fallback := UIManager default uiProcess. Processor scanSchedule: [:p | suspendedContext sender == nil usually means that process is only scheduled but had no chance to run ((p ~~ Processor backgroundProcess) and: [ p suspendedContext sender notNil]) ifTrue: [ p ~~ WeakArray runningFinalizationProcess ifTrue: [^p] ifFalse: [fallback := p]] ] startingAt: Processor activePriority. ^fallback in todays Moose 4.8 (on Pharo 20608) on the april 10 VM allows for better interruption, up to the point where the system runs out of memory without a lowspace warning after I assume trying to collect garbage for 20 minutes or so. Stephan
Re: [Pharo-dev] Cloud Hosting why/when
Thank you Steven, Good to get some ideas on where and when to use or not cloud services. James Foster asked: Do Amazon's data centers outside the US qualify for EU usage? According to the discussions (I'm not a lawyer), the FISA Amendments Acts and the Patriot Act conflict with EU legislation for all US owned companies. The suggestion is that only putting encrypted data on a US owned cloud can be secure enough (not processing any unencrypted data). Stephan
Re: [Pharo-dev] Cloud Hosting why/when?
Another issue is, at least in the EU, the Data Protection Directive. AFAIK no cloud provider from the US or with US ownership can currently comply with that. Stephan
Re: [Pharo-dev] Barcodes
Guillaume wrote: I prefer the first one, creating a separate package depending on both. Done merged. Now there is an ArteBar package in Artefact. Configuration not changed. Stephan
