Re: [Pharo-dev] [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0
Thanks for the explanation. I suspected something like that (interestingly when I tried disabling all options on my Mac it worked fine…). I’ll dig some more and let you know. On 25.11.2013, at 18:42, Eliot Miranda eliot.mira...@gmail.com wrote: On Mon, Nov 25, 2013 at 9:37 AM, Sven Van Caekenberghe s...@stfx.eu wrote: On 25 Nov 2013, at 17:56, Clément Bera bera.clem...@gmail.com wrote: Yeah you cannot compile without inlining specific messages. You can disable inlining of #timesRepeat: at image level because we added it for fun to see if it was easy to do in Opal. Now all other optimizations were in the old compiler and are mandatories. However, you can now in Opal disable these optimized messages in a restricted area (such as a class and its subclasses). To me, it is kind of a bug that we cannot disable those optimizations, we should be able to do it (so 1 day in the very very far future we could have the JIT inlining these control structure allowing us to implement all these inlined messages in all classes). But one thing is that some methods such as #whileTrue are not implemented in a way they really work (they have not stop condition, so if the compiler does not inline it, it gives you an infinite loop). Another thing is the interrupt point problem as Marcus said. I don't think your other bug is related Opal optimization, only #timesRepeat: is new and therefore can be faulty (and in this case, the bytecode is correct, so I guess it is faulty because it removes an interrupt point). It is a bit scary that there is no explicit, crystal clear list of those interrupt critical points, especially if skipping them can lead to VM crashes. Before we raise the alarm the first thing is to identify the cause of the VM crash. It could still be a VM bug. First track down the bug. Don't try and find work-arounds. Try and find the cause. Only then can one develop a correct fix. Anything else buries the true cause under hacks, a process that is truly scary ;-) 2013/11/25 Marcus Denker marcus.den...@inria.fr On 25 Nov 2013, at 16:26, Max Leske maxle...@gmail.com wrote: Thanks Clément, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like there’s another (Opal related?) problem (with the exact same symptoms…). I’ve tried disabling all options, just to see what happens: all builds fail with SegFaults… You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problem… Marcus -- best, Eliot
Re: [Pharo-dev] Is there an up to date version of ConfigurationOfFuel?
What do you mean by up to date? For 3.0 #development is current. On 24.11.2013, at 21:04, Stéphane Ducasse stephane.duca...@inria.fr wrote: Is there an up to date version of ConfigurationOfFuel? Stef
Re: [Pharo-dev] Is there an up to date version of ConfigurationOfFuel?
I’m currently making some fixes to the configuration but basically you can just use the latest one. That should do the trick. On 24.11.2013, at 22:45, Stéphane Ducasse stephane.duca...@inria.fr wrote: What do you mean by up to date? For 3.0 #development is current. I want to try to unload fuel and reload it. I guess that it will be easy since you maintain it. I want to do that to many parts (all) of the system. Is there an up to date version of ConfigurationOfFuel?
Re: [Pharo-dev] vmLatest zeroconf problem
Might be related to the maintenance at INRIA. On 11.11.2013, at 09:07, p...@highoctane.be wrote: Now get.pharo.org looks like dead.
Re: [Pharo-dev] vmLatest zeroconf problem
Does the same happen with bash? The scripts were written for bash, not sh, so there might be slight differences in execution… On 10.11.2013, at 22:06, Tudor Girba tu...@tudorgirba.com wrote: I seem to get a problem with the latest zero conf scripts when downloading only the latest VM. I can reproduce the problem on a Mac like this: If I do: curl -L get.pharo.org/30+vmLatest | sh ./pharo-ui == the dialog opens fine But, if I do: curl -L get.pharo.org/vmLatest | sh ./pharo-ui == ERROR: ./pharo-ui: line 11: -n: command not found Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] Fwd: [ci-announces] CI shutdown on the 11th of November
files.pharo.org and get.pharo.org will remain DOWN for the rest of the day. Begin forwarded message: From: Emmanuel Jeanvoine emmanuel.jeanvo...@inria.fr Subject: Re: [ci-announces] CI shutdown on the 11th of November Date: 9. November 2013 09:00:31 MEZ To: ci-announ...@inria.fr Reply-To: Emmanuel Jeanvoine emmanuel.jeanvo...@inria.fr On Thu, 07 Nov 2013, Emmanuel Jeanvoine wrote: Dear users, The 11th of November, the IT department will stop the national IT services. As a consequence, the CI service will be stopped. In order to prevent any trouble, we strongly advice users to perform the following steps before the 11th of November (Sunday evening at the very latest): - stop the Jenkins instance of your project (see https://ci.inria.fr/project/PROJECTNAME/show#ci) - stop all the slaves related to your project (directly with a clean shutdown in the slave or from https://ci.inria.fr/project/PROJECTNAME/show#slaves) By the way, if you notice unused slaves in your project, you are strongly encouraged to removed them (delete button on https://ci.inria.fr/project/PROJECTNAME/show#slaves, or destroy button directly on the CloudStack interface). Stopping the unused slaves is not enough to free the related resources. Monday in the morning, the remaining running slaves will be stopped. After the maintenance, the Jenkins instances and the slaves will be restarted. Thus we hope that the service will be fully available on Tuesday in the morning. Anyway, since it is an heavy operation (major changes on the network of the datacenter) issues might occur, so we will communicate if communication means are available ;). Thank you for your understanding, Emmanuel This is a reminder, you still have the opportunity to shutdown your slaves and jenkins instances before tomorrow evening. This might be useful to prevent slaves and jenkins corruption. Regards, Emmanuel
Re: [Pharo-dev] Bugs and files sites down?
I just forwarded the INRIA announcement to the list: due to maintenance files.pharo.org and get.pharo.org will remain down for the day. Max On 11.11.2013, at 13:36, Pablo Estefó pest...@gmail.com wrote: Hi guys, We are trying to start the Pharo Sprint here at DCC UChile but the sites files.pharo.org / bugs.pharo.org seems to be down. Cheers, Pablo
Re: [Pharo-dev] Bugs and files sites down?
pharo.fogbugz.com is still online though. On 11.11.2013, at 13:47, Max Leske maxle...@gmail.com wrote: I just forwarded the INRIA announcement to the list: due to maintenance files.pharo.org and get.pharo.org will remain down for the day. Max On 11.11.2013, at 13:36, Pablo Estefó pest...@gmail.com wrote: Hi guys, We are trying to start the Pharo Sprint here at DCC UChile but the sites files.pharo.org / bugs.pharo.org seems to be down. Cheers, Pablo
Re: [Pharo-dev] Unexpected block variable change of value
Not sure if it’s related to your issue but I’ve been seeing swapped temporary
variables in the debugger. The value used for execution is correct but in the
view two variables will have the value of the other.
Are you sure that the value *effectively* changes or could it be a
visualization problem?
Max
On 11.11.2013, at 17:29, b...@openinworld.com wrote:
I'm not sure if I'm missing something, but there seems some strange behavior
that I don't understand. The value of a block variable changes when stepping
over a method that acts on that variable. I encountered this in Spec, but
that seems co-incidental to the behaviour.
SETUP
1. The attached My-Spec-Tutorial-BenComan.1.mcz (i.e. Bahman's tutorial)
was loaded into build #30564.
2. A breakpoint was inserted after the first e generateArguments in...
SpecRowLayoutprivateAsArray
| result shouldCheckSplitters |
result := OrderedCollection new.
shouldCheckSplitters := false. (self commands reject: [:e | e
isSplitter ]) do: [:e |
...lots..hidden.for..conciseness
e generateArguments.
self haltOnce. --
e asSpecElements do: [:el |
result add: el ]].
3. The following was evaluated...
Halt enableHaltOnce.
MyFirstWindow new openWithSpec: #defaultSpec.
OBSERVATION
1. When the debugger opened at the breakpoint
e = a SpecLayoutAdd
2. But after stepping over #asSpecElements
e = an OrderedCollection()
So how did the value of 'e' change?
Where...
SpecLayoutAdd(SpecLayoutSend)asSpecElements
^ {self selector.}, self arguments
SpecLayoutAdd(SpecLayoutSend)selector
^ selector
SpecLayoutAdd(SpecLayoutSend)arguments
^ arguments
This was on Windows 7. Since files.pharo.org is offline, I wasn't able to
try a newer VM. My current was...
NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
git://gitorious.org/cogvm/blessed.git Commit:
412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By:
Esteban Lorenzano esteba...@gmail.com Jenkins build #14535
Win32 built on Mar 13 2013 18:49:42 Compiler: 4.6.2
VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit:
412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By:
Esteban Lorenzano esteba...@gmail.com Jenkins build #14535
NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
cheers -ben
My-Spec-Tutorial-BenComan.1.mcz
Re: [Pharo-dev] FileSystem memory bug?
On 08.11.2013, at 13:59, Sven Van Caekenberghe s...@stfx.eu wrote: Hi Martin, I would guess that the stream created by the memory filesystem are binary, not character, as STON expects. Good point, although currently ascii mode is still default I think. Try sending #ascii to the stream. That might help. Sven On 08 Nov 2013, at 13:55, Martin Dias tinchod...@gmail.com wrote: Hi, I'm working in latest Pharo (30577) with STON (bleeding edge) and I get MNU:SmallIntegerisSeparator when I evaluate the code below. Is my code wrong? The idea is to make my test suite work in the memory file system. | fileSystem | fileSystem := FileSystem memory. (fileSystem / 'file.txt') ensureCreateFile. STON writer on: (fileSystem / 'file.txt') writeStream; nextPut: 'hi'. STON reader on: (fileSystem / 'file.txt') readStream; next. Thanks in advance. Martín
Re: [Pharo-dev] No decompile string at all, bad idea?
On 06.11.2013, at 08:57, Marcus Denker marcus.den...@inria.fr wrote: On 06 Nov 2013, at 08:53, Max Leske maxle...@gmail.com wrote: On 06.11.2013, at 08:05, Marcus Denker marcus.den...@inria.fr wrote: On 05 Nov 2013, at 20:37, Mariano Martinez Peck marianop...@gmail.com wrote: Hi. From what I understand you removed the old Compiler but yet Opal does not support compiling. Also, #sourceCode was changed etc... That means that there is no way to see the decompiled string of a method? Yes. Which means I cannot deploy and image without sources and then browse/debug/inspect/write pharoDebug.log etc because we don't have even the decompile string??? Exactly. But this is just temporary, .sources and .changes will go away in Pharo4 and there will be just a .pharo4 image file. By “temporary” do you mean decompilation will come back? No, we will have a high-level representation of Methods that replace (from the standpoint of reflection) the incomplete bytecode representation, Ok, good to know. Serializing compiled methods is not fun either since we cannot decompile it after... You can embedd the source into the method before serialising. That means storing redundant information though (if the user is only interested in functionality) and that will increase file size, and serialization/materalzation time. So it’s not an ideal situation. The thing is that we can either not move or move step by step taking (sometimes) into account that things are sub-optimal for a little while. I agree that that’s sometimes necessary. You can envision the current implementation as a peak on a map: it’s a very good local optimum. But *Much* better is possible. Maybne a local metaphor: We are in the Gurten now, you can not reach the Eiger without going down for a while. Haha :) nice! That means we’ll have to figure something out for Fuel to work with not installed compiled methods in 3.0. Thanks for the explanation. Marcus
Re: [Pharo-dev] Bug? AdditionalMethodState suddenly stores Associations
https://pharo.fogbugz.com/f/cases/12077/MNU-in-AdditionalMethodState-analogousCodeTo On 06.11.2013, at 08:53, Max Leske maxle...@gmail.com wrote: Thanks Marcus. I’ll open a bug report. On 06.11.2013, at 08:14, Marcus Denker marcus.den...@inria.fr wrote: On 05 Nov 2013, at 19:48, Max Leske maxle...@gmail.com wrote: I discovered that AdditionalMethodState now (sometimes) stores Associations, not only Pragmas and Messages. That seems to work fine so fare but leads to an exception if #analogousCodeTo: is sent to a state which stores an Association. I think this is the case when the method stored general properties (non-source visible). see propertyValueAt:put: Can someone please confirm that this is a bug? I guess the bug is that analogousCodeTo: should handle the properties correctly. I think just ignoring them would be fine, as they are not part of code, but meta. Marcus
[Pharo-dev] HDTestReport improvements: please integrate
I’ve made a few minor improvements to HDTestReport with the following effects: - progress log will now print end of suite and the stream will be properly closed - progress log will print the start of the case *before* the case starts (at the moment that happens after the case has run. The problem is of course that if the VM crashes during that test you can not find out which test caused the crash) I’d very much appreciate it if someone could install these changes on Jenkins because I need them to debug the VM SegFaults that appear during the Fuel tests. Cheers, Max HDTestReport.MaxLeske.cs Description: Binary data
Re: [Pharo-dev] HDTestReport improvements: please integrate
https://pharo.fogbugz.com/f/cases/12079/HDTestReport-improvements Slice: Name: SLICE-Issue-12079-HDTestReport-improvements-MaxLeske.1 Author: MaxLeske Time: 6 November 2013, 2:07:20.708816 pm UUID: 16baecc6-cbfc-4309-a6fc-908bc542e68c Ancestors: Dependencies: HudsonBuildTools20-MaxLeske.52 * progress log will now print end of suite and the stream will be properly closed * progress log will print the start of the case *before* the case starts (at the moment that happens after the case has run. The problem is of course that if the VM crashes during that test you can not find out which test caused the crash) On 06.11.2013, at 13:46, Camillo Bruni camillobr...@gmail.com wrote: could you open an issue on fogbugz and propose a slice? On 2013-11-06, at 11:17, Max Leske maxle...@gmail.com wrote: I’ve made a few minor improvements to HDTestReport with the following effects: - progress log will now print end of suite and the stream will be properly closed - progress log will print the start of the case *before* the case starts (at the moment that happens after the case has run. The problem is of course that if the VM crashes during that test you can not find out which test caused the crash) I’d very much appreciate it if someone could install these changes on Jenkins because I need them to debug the VM SegFaults that appear during the Fuel tests. Cheers, Max HDTestReport.MaxLeske.cs
Re: [Pharo-dev] [Edu] 3-day project with high school students
PhaROS might be interesting: controlling robots with Pharo. On 06.11.2013, at 12:37, roberto.mine...@usi.ch wrote: Hi, I would like to hear an opinion from you. I need to organize a 3-day project with high-school students. In short they will come to our University and I am the responsible to guide them to do “something” to introduce them to programming. The assumption is that they have zero background about programming. In this mailing list I’ve read a couple of previous discussions about how to start to use Pharo and ST for educational purposes, but I’d love to collect additional opinions. Visual programming is one of the thing that came to my mind. I though about Phratch. Michele suggested me to look also at Etoys (squeakland.org) and I will start to look at thesee two tools in the next days. Any opinion, proposal, tool, article, suggestion, hint on the topic is really welcome. Thanks in advance, Roberto
[Pharo-dev] Bug? AdditionalMethodState suddenly stores Associations
I discovered that AdditionalMethodState now (sometimes) stores Associations, not only Pragmas and Messages. That seems to work fine so fare but leads to an exception if #analogousCodeTo: is sent to a state which stores an Association. Can someone please confirm that this is a bug? Cheers, Max
[Pharo-dev] builds
I’ve temporarily disabled the Fuel builds. Martin and I discovered VM crashes related to (maybe) garbage collection during our test runs. So right now a lot of builds are crashing. We’ll keep investigating so as to reenable the builds. Max
Re: [Pharo-dev] No decompile string at all, bad idea?
On 06.11.2013, at 08:05, Marcus Denker marcus.den...@inria.fr wrote: On 05 Nov 2013, at 20:37, Mariano Martinez Peck marianop...@gmail.com wrote: Hi. From what I understand you removed the old Compiler but yet Opal does not support compiling. Also, #sourceCode was changed etc... That means that there is no way to see the decompiled string of a method? Yes. Which means I cannot deploy and image without sources and then browse/debug/inspect/write pharoDebug.log etc because we don't have even the decompile string??? Exactly. But this is just temporary, .sources and .changes will go away in Pharo4 and there will be just a .pharo4 image file. By “temporary” do you mean decompilation will come back? Serializing compiled methods is not fun either since we cannot decompile it after... You can embedd the source into the method before serialising. That means storing redundant information though (if the user is only interested in functionality) and that will increase file size, and serialization/materalzation time. So it’s not an ideal situation. Marcus
Re: [Pharo-dev] Bug? AdditionalMethodState suddenly stores Associations
Thanks Marcus. I’ll open a bug report. On 06.11.2013, at 08:14, Marcus Denker marcus.den...@inria.fr wrote: On 05 Nov 2013, at 19:48, Max Leske maxle...@gmail.com wrote: I discovered that AdditionalMethodState now (sometimes) stores Associations, not only Pragmas and Messages. That seems to work fine so fare but leads to an exception if #analogousCodeTo: is sent to a state which stores an Association. I think this is the case when the method stored general properties (non-source visible). see propertyValueAt:put: Can someone please confirm that this is a bug? I guess the bug is that analogousCodeTo: should handle the properties correctly. I think just ignoring them would be fine, as they are not part of code, but meta. Marcus
Re: [Pharo-dev] Github and Pharo
Thanks guys :) On 04.11.2013, at 19:35, kilon alios kilon.al...@gmail.com wrote: Yeah I agree, this is an awesome project and thank you for your hard work :) On Mon, Nov 4, 2013 at 8:12 PM, GOUBIER Thierry thierry.goub...@cea.fr wrote: Hi Max, I saw you were on it :) It's a huge effort you're undertaking. I learned a bit about git internal storage stepping through the code. Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Max Leske [maxle...@gmail.com] Date d'envoi : lundi 4 novembre 2013 17:44 À : Pharo Development List Objet : Re: [Pharo-dev] Github and Pharo FileSystem-Git is basically in alpha at the moment… I’m rewriting it. On 04.11.2013, at 17:04, Goubier Thierry thierry.goub...@cea.fr wrote: Ok, I tried a bit with FileSystem-Git, but it seems there is still a bit of work to do... I tried on one of my work repository, and: - it failed trying to uft8convert a packed data file. So I corrected the error (get the stream as binary!) and - It failed looking for one of the commit IDs I found the ref in a pack file; apparently, it's not looking in there... I'm forcing a read of the pack files in there - Yet another utf8convert error on binary data Corrected, I got the pack files, but the index isn't telling me much. I tried to list the objects in it... Unknown compression method error. There's a huge amount of code in there, it's a bit frightening. I think I'll stay with OSProcess a bit longer ;) Thierry Le 04/11/2013 14:28, Goubier Thierry a écrit : Le 04/11/2013 14:09, David T. Lewis a écrit : On Mon, Nov 04, 2013 at 01:58:29PM +0100, Goubier Thierry wrote: Le 04/11/2013 12:11, kilon alios a ?crit : yeap filetree did the trick here. However it does not allow to browse through the git commits as gitfiletree does, the only commit available is the last commit. I took a look at CommandShell and friends and they all look pretty much very broken. For example in workspace I executed [ CommandShellTranscript open.] and trying ls or dir it creates an error because it add C path inside pharo subdirectories. Dont know if this is normal behavior. Use CommandShell open rather than CommandShellTranscript open. I hope someone with more knowledge than me of OSProcess under windows will have a look :) OSProcess support for Windows is incomplete, so this will probably not do what you need. If the OSProcess is included in the Windows VM, it will let you run a Windows program, but it will not do most of the other things that you expect from OSProcess. Check http://www.squeaksource.com/ProcessWrapper.html for a possible alternative. Thanks Dave; no easy solution on that, it seems. I'll have a look then with FileSystem-Git, this one may be a more portable solution. Windows is still a world apart from the rest :( Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] Fuel: fix for Squeak trunk
Good idea. What would we put there? I can’t think of anything else than globals… If globals is the only thing then I’m not sure that it’s worth the effort. Max On 04.11.2013, at 01:04, Mariano Martinez Peck marianop...@gmail.com wrote: I would love a quick and easy refactor in which we add a FLSmalltalkPlatform with some utility methods such as #globals. Then concrete subclasses like FLPharoPlatform which implements #globals in our current way. That refactor would be quite easy and useful. I don't want to add Grease or whatever layer.. but just very concrete examples like this one. Thoughts? On Sat, Nov 2, 2013 at 12:46 PM, Max Leske maxle...@gmail.com wrote: Thanks Nicolas, we’ll take a look at it. Max On 02.11.2013, at 14:43, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I've opened https://code.google.com/p/fuel/issues/detail?id=204 with an attachment Also note https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteger-up-to-32bits-magnitude 2013/11/2 Max Leske maxle...@gmail.com So far we don’t have a public inbox and I’m not too familiar with STHub and read/write permissions. Concerning your suggestion from the other thread a public inbox would certainly make sense though. I’ll let you know what we can come up with (STHub seems to be down right now so I can’t even give you access right now. But you can send me your fix through mail). Max On 02.11.2013, at 09:46, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Thanks, and is there a public .mcz inbox, or does it require special rights? 2013/11/2 Max Leske maxle...@gmail.com The Fuel bug tracker is hosted by Google: https://code.google.com/p/fuel/ On 01.11.2013, at 22:42, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I have an easy fix for Fuel on Squeak trunk. It concerns the FuelCompatibility layer, so I hesitate to publish on Pharo fogbugz... Is there a dedicated bug tracker? What is the preferred procedure? Nicolas -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] About BitBlt current - BitBlt (Fuel)
Did #hackBits: come with Fuel? It’s not an extension method… On 04.11.2013, at 01:10, Mariano Martinez Peck marianop...@gmail.com wrote: Indeed. That's why I want to move it to a separate class. On Fri, Nov 1, 2013 at 5:18 PM, Max Leske maxle...@gmail.com wrote: Wow… Form is mindnumbing… On 30.10.2013, at 23:00, Mariano Martinez Peck marianop...@gmail.com wrote: hehehe sorry, it was #hackBits: :) On Wed, Oct 30, 2013 at 6:52 PM, Max Leske maxle...@gmail.com wrote: Where did you find that method? I couldn’t find any implementors or references… On 30.10.2013, at 21:42, Mariano Martinez Peck marianop...@gmail.com wrote: BTWit is time to move the hashBits: to a more general classbut the question is where? On Wed, Oct 30, 2013 at 6:21 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Fuel was using BitBlt current and I change that to BitBlt Stef On Oct 29, 2013, at 10:55 AM, Max Leske maxle...@gmail.com wrote: Stef, what exactly is the influence on Fuel? I looked at the changes of your slice and couldn’t find anything… Max On 25.10.2013, at 16:26, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I just pushed a change cleaning some strange usage. BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). Apparently in Squeak they removed it too. Now it touches Fuel so Fuel guys can you merge on your side too? https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt Stef -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Update Fuel documentation
Thanks Nicolas. We’ll update the docs and fix the configuration. Has 4.5 been released? We had decided to wait with support for 4.5 until it was released to prevent repetitive work. If 4.5 has indeed been released we’ll of course add support for 4.5. Cheers, Max On 01.11.2013, at 21:37, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: This page http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/Installation has obsolete information, at least for Squeak installation. This is because ConfigurationOfFuel-MaxLeske.178 still points to old repository http://ss3.gemstone.com/ss/Fuel.html which has been drained... ConfigurationOfFuel-MartinDias.209 should be a better starting point. In latest Squeak trunk there is another problem: lack of squeak4.5.x support both in ConfigurationOfFuel and MetacelloSqueakPlatformdefaultPlatformAttributes. But it's another problem, not related to documentation
Re: [Pharo-dev] Fuel: fix for Squeak trunk
The Fuel bug tracker is hosted by Google: https://code.google.com/p/fuel/ On 01.11.2013, at 22:42, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I have an easy fix for Fuel on Squeak trunk. It concerns the FuelCompatibility layer, so I hesitate to publish on Pharo fogbugz... Is there a dedicated bug tracker? What is the preferred procedure? Nicolas
Re: [Pharo-dev] Fuel: fix for Squeak trunk
So far we don’t have a public inbox and I’m not too familiar with STHub and read/write permissions. Concerning your suggestion from the other thread a public inbox would certainly make sense though. I’ll let you know what we can come up with (STHub seems to be down right now so I can’t even give you access right now. But you can send me your fix through mail). Max On 02.11.2013, at 09:46, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Thanks, and is there a public .mcz inbox, or does it require special rights? 2013/11/2 Max Leske maxle...@gmail.com The Fuel bug tracker is hosted by Google: https://code.google.com/p/fuel/ On 01.11.2013, at 22:42, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I have an easy fix for Fuel on Squeak trunk. It concerns the FuelCompatibility layer, so I hesitate to publish on Pharo fogbugz... Is there a dedicated bug tracker? What is the preferred procedure? Nicolas
Re: [Pharo-dev] Fuel: fix for Squeak trunk
Thanks Nicolas, we’ll take a look at it. Max On 02.11.2013, at 14:43, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I've opened https://code.google.com/p/fuel/issues/detail?id=204 with an attachment Also note https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteger-up-to-32bits-magnitude 2013/11/2 Max Leske maxle...@gmail.com So far we don’t have a public inbox and I’m not too familiar with STHub and read/write permissions. Concerning your suggestion from the other thread a public inbox would certainly make sense though. I’ll let you know what we can come up with (STHub seems to be down right now so I can’t even give you access right now. But you can send me your fix through mail). Max On 02.11.2013, at 09:46, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Thanks, and is there a public .mcz inbox, or does it require special rights? 2013/11/2 Max Leske maxle...@gmail.com The Fuel bug tracker is hosted by Google: https://code.google.com/p/fuel/ On 01.11.2013, at 22:42, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I have an easy fix for Fuel on Squeak trunk. It concerns the FuelCompatibility layer, so I hesitate to publish on Pharo fogbugz... Is there a dedicated bug tracker? What is the preferred procedure? Nicolas
Re: [Pharo-dev] Proposal for a Topic for the bachelor/master list [safe-image for teaching]
I think that’s a good idea. Obviously that’s something that none of us developers want in the system but it would be good to have it from a promotional point of view I guess. Could applications like Dr. Geo benefit from such an environment? Max On 01.11.2013, at 19:56, Gisela Decuzzi giseladecu...@gmail.com wrote: Hi, I don't know where to send the proposal and I think that the list would be a good place to talk about it. The main idea is to have a safe image, or a way to block or restrict the modificable parts in the system, in order to avoid mistakes during the learning. It could include protected packages, reduced browsers showing by default user packages, configurable rules (by example: you can not create a class with empty category, you can not create a class with the same name that a known one). Maybe we can have a way to configure or to ask for permission to modificate some parts of the system. Also, some filters during debugging, to avoid protected code. An easy way to obtain that image The idea is to reduce the common errors that we make when we start programming also to help teachers.
Re: [Pharo-dev] About BitBlt current - BitBlt (Fuel)
Wow… Form is mindnumbing… On 30.10.2013, at 23:00, Mariano Martinez Peck marianop...@gmail.com wrote: hehehe sorry, it was #hackBits: :) On Wed, Oct 30, 2013 at 6:52 PM, Max Leske maxle...@gmail.com wrote: Where did you find that method? I couldn’t find any implementors or references… On 30.10.2013, at 21:42, Mariano Martinez Peck marianop...@gmail.com wrote: BTWit is time to move the hashBits: to a more general classbut the question is where? On Wed, Oct 30, 2013 at 6:21 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Fuel was using BitBlt current and I change that to BitBlt Stef On Oct 29, 2013, at 10:55 AM, Max Leske maxle...@gmail.com wrote: Stef, what exactly is the influence on Fuel? I looked at the changes of your slice and couldn’t find anything… Max On 25.10.2013, at 16:26, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I just pushed a change cleaning some strange usage. BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). Apparently in Squeak they removed it too. Now it touches Fuel so Fuel guys can you merge on your side too? https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt Stef -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] 11635: Race condition in SequenceableCollectionshuffle
Name: SLICE-Issue-11635-Race-condition-in-SequenceableCollectionshuffle-MaxLeske.2 Author: MaxLeske Time: 30 October 2013, 1:41:57.198092 pm UUID: c3d51645-7e81-4997-b74c-545bf7ef60b0 Ancestors: Dependencies: Collections-Abstract-MaxLeske.231, Collections-Unordered-MaxLeske.175 made changes as detailed on the mailing list * shuffle ^ self shuffleBy: Random new * shuffled ^ self copy shuffle * removed #shuffledBy: * Matrix uses #shuffleBy: (on an explicit copy) instead of #shuffledBy: On 01.10.2013, at 17:06, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On Sep 28, 2013, at 10:59 , Max Leske maxle...@gmail.com wrote: Thanks for the feedback guys. Based on the discussion I propose a different set of changes: 1. shuffle ^ self shuffleBy: Random new 2. shuffled ^ self copy shuffle 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to) I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace). Also open for discussion is the use of CollectionrandomForPicking and CollectionmutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. Cheers, Max +1 from me on all three suggestions, as you might guess. :) As for #atRandom using Random new, the performance hit and seed quality would be much greater concerns, as the Random instance would only be used once per invocation. At this point in time there's no good alternatives to the current approach, but renaming the mutex/shared variable to reflect its singular use would be one possible improvement, I guess. Cheers, Henry
[Pharo-dev] Changing non-copying selectors to #...InPlace
To continue the discussion on this topic (stemming from issue 11635) I’m starting a new thread. Please share your thoughts. Form the other thread: Personally I'm for more intention revealing selectors; I quite like #shuffled and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sorted, #sortInPlace). My proposition is to keep the selectors named #…d (#shuffled, #sorted, etc.), which operate on a copy, and rename the others (#shuffle, #sort, etc…) to #…InPlace (#shuffleInPlace, #sortInPlace, etc.). The rational behind this is that (to my mind) the current scheme is not intention revealing (e.g. #shuffle vs. #shuffled). Which is especially problematic for newcomers. Max
[Pharo-dev] Preventing wrong use of Collection#randomForPicking
To continue the discussion on this topic (stemming from issue 11635) I’m starting a new thread. Please share your thoughts. From the other thread: Also open for discussion is the use of CollectionrandomForPicking and CollectionmutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. #randomForPicking answers a Random stored in a class variable. Access to this variable is protected by a Mutext stored in a class variable (#mutexForPicking). The problem, as revealed by issue 11635, is of course that you have to know that you may only use that Random object if you also protect access to it with the class side Mutex. Otherwise race conditions can occur. #atRandom is one prominent user of #randomForPicking and #mutexForPicking. Henrik’s thoughts: As for #atRandom using Random new, the performance hit and seed quality would be much greater concerns, as the Random instance would only be used once per invocation. At this point in time there's no good alternatives to the current approach, but renaming the mutex/shared variable to reflect its singular use would be one possible improvement, I guess. So one possibility would be rename these methods, for example to #atRandomMutex and #atRandomRandom (no, I haven’t given much thought to the names :) ). Max
Re: [Pharo-dev] About BitBlt current - BitBlt (Fuel)
Where did you find that method? I couldn’t find any implementors or references… On 30.10.2013, at 21:42, Mariano Martinez Peck marianop...@gmail.com wrote: BTWit is time to move the hashBits: to a more general classbut the question is where? On Wed, Oct 30, 2013 at 6:21 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Fuel was using BitBlt current and I change that to BitBlt Stef On Oct 29, 2013, at 10:55 AM, Max Leske maxle...@gmail.com wrote: Stef, what exactly is the influence on Fuel? I looked at the changes of your slice and couldn’t find anything… Max On 25.10.2013, at 16:26, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I just pushed a change cleaning some strange usage. BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). Apparently in Squeak they removed it too. Now it touches Fuel so Fuel guys can you merge on your side too? https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt Stef -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] About BitBlt current - BitBlt (Fuel)
Stef, what exactly is the influence on Fuel? I looked at the changes of your slice and couldn’t find anything… Max On 25.10.2013, at 16:26, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I just pushed a change cleaning some strange usage. BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). Apparently in Squeak they removed it too. Now it touches Fuel so Fuel guys can you merge on your side too? https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt Stef
Re: [Pharo-dev] About BitBlt current - BitBlt (Fuel)
Thanks Mariano, I’ll look at that. On 29.10.2013, at 15:39, Mariano Martinez Peck marianop...@gmail.com wrote: Max, we use a primitive from BitBtl to perform writing of word-like instances (Bitmaps etc). It makes writing word objects way faster. Check the method #copyWordObjectToBuffer: aWordObject and its senders. Cheers, On Tue, Oct 29, 2013 at 6:55 AM, Max Leske maxle...@gmail.com wrote: Stef, what exactly is the influence on Fuel? I looked at the changes of your slice and couldn’t find anything… Max On 25.10.2013, at 16:26, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I just pushed a change cleaning some strange usage. BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). Apparently in Squeak they removed it too. Now it touches Fuel so Fuel guys can you merge on your side too? https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt Stef -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] About BitBlt current - BitBlt (Fuel)
Bleeding edge only: Name: Fuel-MaxLeske.787 Author: MaxLeske Time: 29 October 2013, 11:41:05.948727 pm UUID: 2199a684-70e6-4dee-b3f1-ee389d959aed Ancestors: Fuel-MarianoMartinezPeck.775, Fuel-MaxLeske.786 merging tips from 3.0 development and fuel repo On 29.10.2013, at 19:56, Max Leske maxle...@gmail.com wrote: Thanks Mariano, I’ll look at that. On 29.10.2013, at 15:39, Mariano Martinez Peck marianop...@gmail.com wrote: Max, we use a primitive from BitBtl to perform writing of word-like instances (Bitmaps etc). It makes writing word objects way faster. Check the method #copyWordObjectToBuffer: aWordObject and its senders. Cheers, On Tue, Oct 29, 2013 at 6:55 AM, Max Leske maxle...@gmail.com wrote: Stef, what exactly is the influence on Fuel? I looked at the changes of your slice and couldn’t find anything… Max On 25.10.2013, at 16:26, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I just pushed a change cleaning some strange usage. BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). Apparently in Squeak they removed it too. Now it touches Fuel so Fuel guys can you merge on your side too? https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt Stef -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?
In my opinion the #fuelAccept: for the meta description object should be overridden and there the behaviour for problematic references should be defined. Roberto, what references does your meta object hold on to? Max On 28.10.2013, at 22:16, Martin Dias tinchod...@gmail.com wrote: On Mon, Oct 28, 2013 at 5:13 PM, roberto.mine...@usi.ch roberto.mine...@usi.ch wrote: The idea is that I have an object (a session) which has meta data (time, duration, author) and some other object inside. I want that Fuel serializes just that object and not pointes to other object, globals and what not. This causes me a lot of troubles, moreover it makes the fuel file bigger than the optimum… Still there is something that I don't understand in your problem. If you just prune the graph, what your objects represent (conceptually) can be lost. Did you pick one of your problematic session objects are explored it until find how the unwanted block closures are referenced? I mean, fuel doesn't invent the unwanted closures magically, you are saying to fuel to serialize the graph with the unwanted objects already there. Cheers, R On Oct 28, 2013, at 4:57 PM, Martin Dias tinchod...@gmail.com wrote: On Mon, Oct 28, 2013 at 4:47 PM, roberto.mine...@usi.ch roberto.mine...@usi.ch wrote: Thanks, On Oct 28, 2013, at 4:36 PM, Martin Dias tinchod...@gmail.com wrote: Currently there is no such option. Maybe it is something which is needed, what do you think? The idea is that, if you serialize: a - b - c fuel actually would encode: a - b - nil that?
Re: [Pharo-dev] About BitBlt current - BitBlt (Fuel)
On it! On 25.10.2013, at 16:26, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I just pushed a change cleaning some strange usage. BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). Apparently in Squeak they removed it too. Now it touches Fuel so Fuel guys can you merge on your side too? https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt Stef
Re: [Pharo-dev] [OT] Git Internals PDF
Thanks Torsten, nice of you to think of us! On 10.10.2013, at 17:14, Torsten Bergmann asta...@gmx.de wrote: A PDF by Scott Chacon about how the Git source code control system stores files and revisions. https://github.com/pluralsight/git-internals-pdf/releases Maybe thats interesting for the people working on Pharo Git
Re: [Pharo-dev] Please contributors fill up this form...
PharoContributor new name: 'Max Leske' email: 'maxle...@gmail.com' description: 'Master student at University of Bern, interested in software development and language design. Author and maintainer of FileSystem-Git, contributor to Fuel. Works for Netstyle.ch and Cmsbox where he uses Pharo for almost everything.' On 09.10.2013, at 13:34, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys I would like to get contributors.pharo.org a bit more representative of Pharo. We should have Previous contributors and enhance the current list. Can you please reply to this mail PharoContributor new name: 'Esteban Lorenzano'; id: 'estebanlm'; email: 'esteba...@gmail.com'; website: 'http://smallworks.eu'; description: 'Pharo core team. Contributor of several projects, including Kernel, DBXTalk, Voyage, Mars, etc. Also I work on the VM.'; image: 'http://www.gravatar.com/avatar/193af464509ae8fbcc04abad70b72fc0?s=120'; yourself Stef
Re: [Pharo-dev] [Issue Tracker] 129 issues tagged 3.0
On 08.10.2013, at 10:51, Marcus Denker marcus.den...@inria.fr wrote: Hello, There are 129 issues that need to be fixed before we can even think about releasing Pharo3: https://pharo.fogbugz.com/f/filters/37/3-0-Work-Needed There are two options: 1) fix all of them. (unrealistic) 2) decided if all of them are real show stoppers, lower it and fix this hopefully smaller number actively. I know people don't like this option 2), but I do not see any realistic alternative. 2) is the way to go. There will be another, better version of Pharo in the future where those bugs can be fixed. Having a release plan and not adhering to it doesn't cater to anything. Marcus
Re: [Pharo-dev] 11635: Race condition in SequenceableCollectionshuffle
bump... Thanks for the feedback guys. Based on the discussion I propose a different set of changes: 1. shuffle ^ self shuffleBy: Random new 2. shuffled ^ self copy shuffle 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to) I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace). Also open for discussion is the use of CollectionrandomForPicking and CollectionmutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. Cheers, Max On 24.09.2013, at 02:33, b...@openinworld.com wrote: Nicolas Cellier wrote: The reason why I don't like the explicit copy, is because this is the default behaviour. In place mutation is an (evil) exception. I'm personnally fine with current conventions: - sort, shuffle, reverse, replace: are imperative, thus you are telling collection, sort yourself ! - sorted clearly sounds as a sorted copy for me. If ever a change was to be made, I would much prefer this to happen on opposite naming, sort - inPlaceSort, or sortYourself :) It's like telling the programmer, hey - a stateful mutation is really what you want, is it? Conventions should encourage good programming practice. Although it makes perfect sense on hearing it, I was explicitly not aware of the convention between 'sort' and 'sorted'. For me, the small difference in letters used between the two doesn't provide a wide enough distinction. Also, regarding not mutating state, I guess I knew that in the back of my head, but it has not generally been an explicit concern of mine while programming. Convention should encourage good programming. So I like the suggestion of inPlaceSort sortYourself. As well as being more intention revealing, the less desirable methods are made less attractive by using a longer name. Perhaps another naming convention could be mutatedSort, or mutSort as a hint that the programmer should consider using these in conjunction with mutexes, or at own risk. cheers -ben 2013/9/23 Stéphane Ducasse stephane.duca...@inria.fr +1 Now I understand the point of max with the name sort/sorted because this is not explicit to me too :) I laways have to think. On Sep 23, 2013, at 6:28 PM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 100% agree. Do it right do it fast. We must not turn usage of the library into something fragile for the sake of speed. We already make the code itself fragile more often than not in term of complexity (harder to understand/test/change). Especially, introduction of shared mutable states (global, class vars, singleton or any other form) should ring an alarm in reviewers head (This is some very old Squeak code in this case, so Squeakers are to blame, but we're all in same bath). 2013/9/23 Henrik Johansen henrik.s.johan...@veloxit.no On Sep 23, 2013, at 3:33 , Max Leske maxle...@gmail.com wrote: If a user is going to modify the same object concurrently, he/she takes care of mutual exclusion. Agreed. BUT: the Random object used by these methods is the same one that is used by #atRandom for instance, hence the race condition. There is no way anyone can safely use these methods without the mutex, single threaded or not. Calls to methods using that same Random object can be all over the place and also in the base system. It seems to me an existing Random instance is used in this case mostly* for performance. One could argue that since the Random in this case is used for a bulk operation, for which the object creation cost is largely amortized for collection sizes 20, it's acceptable to instead use Random new by default, which wouldn't suffer from the same race conditions. While still slower than a mutex-protected version for single-threaded code, it would also scale correctly if the users (and vm) are actually multi-threaded. [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffle] bench '208,000 per second.' '222,000 per second.' '223,000 per second.' [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleWithMutex] bench '188,000 per second.' '186,000 per second.''184,000 per second.' [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleNewRandom] bench '167,000 per second.' '166,000 per second.' '167,000 per second.' Cheers, Henry * Low seed entropy is another issue, but if purely random shuffling is a critical requirement, one shouldn't use the default Random generator anyways...
Re: [Pharo-dev] 11635: Race condition in SequenceableCollectionshuffle
Thanks for the feedback guys. Based on the discussion I propose a different set of changes: 1. shuffle ^ self shuffleBy: Random new 2. shuffled ^ self copy shuffle 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to) I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace). Also open for discussion is the use of CollectionrandomForPicking and CollectionmutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. Cheers, Max On 24.09.2013, at 02:33, b...@openinworld.com wrote: Nicolas Cellier wrote: The reason why I don't like the explicit copy, is because this is the default behaviour. In place mutation is an (evil) exception. I'm personnally fine with current conventions: - sort, shuffle, reverse, replace: are imperative, thus you are telling collection, sort yourself ! - sorted clearly sounds as a sorted copy for me. If ever a change was to be made, I would much prefer this to happen on opposite naming, sort - inPlaceSort, or sortYourself :) It's like telling the programmer, hey - a stateful mutation is really what you want, is it? Conventions should encourage good programming practice. Although it makes perfect sense on hearing it, I was explicitly not aware of the convention between 'sort' and 'sorted'. For me, the small difference in letters used between the two doesn't provide a wide enough distinction. Also, regarding not mutating state, I guess I knew that in the back of my head, but it has not generally been an explicit concern of mine while programming. Convention should encourage good programming. So I like the suggestion of inPlaceSort sortYourself. As well as being more intention revealing, the less desirable methods are made less attractive by using a longer name. Perhaps another naming convention could be mutatedSort, or mutSort as a hint that the programmer should consider using these in conjunction with mutexes, or at own risk. cheers -ben 2013/9/23 Stéphane Ducasse stephane.duca...@inria.fr +1 Now I understand the point of max with the name sort/sorted because this is not explicit to me too :) I laways have to think. On Sep 23, 2013, at 6:28 PM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 100% agree. Do it right do it fast. We must not turn usage of the library into something fragile for the sake of speed. We already make the code itself fragile more often than not in term of complexity (harder to understand/test/change). Especially, introduction of shared mutable states (global, class vars, singleton or any other form) should ring an alarm in reviewers head (This is some very old Squeak code in this case, so Squeakers are to blame, but we're all in same bath). 2013/9/23 Henrik Johansen henrik.s.johan...@veloxit.no On Sep 23, 2013, at 3:33 , Max Leske maxle...@gmail.com wrote: If a user is going to modify the same object concurrently, he/she takes care of mutual exclusion. Agreed. BUT: the Random object used by these methods is the same one that is used by #atRandom for instance, hence the race condition. There is no way anyone can safely use these methods without the mutex, single threaded or not. Calls to methods using that same Random object can be all over the place and also in the base system. It seems to me an existing Random instance is used in this case mostly* for performance. One could argue that since the Random in this case is used for a bulk operation, for which the object creation cost is largely amortized for collection sizes 20, it's acceptable to instead use Random new by default, which wouldn't suffer from the same race conditions. While still slower than a mutex-protected version for single-threaded code, it would also scale correctly if the users (and vm) are actually multi-threaded. [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffle] bench '208,000 per second.' '222,000 per second.' '223,000 per second.' [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleWithMutex] bench '188,000 per second.' '186,000 per second.''184,000 per second.' [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleNewRandom] bench '167,000 per second.' '166,000 per second.' '167,000 per second.' Cheers, Henry * Low seed entropy is another issue, but if purely random shuffling is a critical requirement, one shouldn't use the default Random generator anyways...
Re: [Pharo-dev] 11635: Race condition in SequenceableCollectionshuffle
On 23.09.2013, at 15:46, Frank Shearar frank.shea...@gmail.com wrote: On 23 September 2013 14:34, Max Leske maxle...@gmail.com wrote: On 23.09.2013, at 15:20, Frank Shearar frank.shea...@gmail.com wrote: On 23 September 2013 14:17, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Here is my 100% personal opinion: I don't like the copyShuffle. To me, the rules are quite clear: sort shuffle reverse etc... - perform modification in place sorted shuffled reversed etc... - answer a copy I hope the methods comments are clear. Does PBE tells about these conventions? It would be a good thing. And I don't like to have mutexes in base library, the less we have, the better. If a user is going to modify the same object concurrently, he/she takes care of mutual exclusion. Especially since locks don't compose. If you _really_ cared about accessing something concurrently, you'd share immutable data structures. I don't quite follow. Could you elaborate? Hopefully it's uncontroversial to assert that locks don't compose. If you only ever have one thread of execution, you don't have any concurrency issues, and locks serve no purpose. If you do have multiple threads of execution, then you have a few choices for sharing data: * you can use a lock around mutable data (but lock-using blocks of code don't compose, so you end up with loads of bugs or deadlocks or nests of locks, or all of the above) * you can share a _copy_ of data. In the latter case, you can share an actual copy, or share a pointer to a structure that can't change. If it can't change, you can't have a reader accidentally reading something from a structure halfway through the writer writing to it. Sharing some immutable chunk of state lets you save the memory taken up by a copy, but also prevents all the race condition things you usually get with shared mutable state. frank Thanks Frank, I get it now. And I agree. frank 2013/9/23 Max Leske maxle...@gmail.com Sven suggested posting this on the list for discussion, so here you go: Maybe this should be discussed on the list, your are going to break API. Note that there is also #sort and #sorted with similar copy behavior. Also, I am not sure that basic operations should use mutexes to protect themselves by default: there is a cost when you are a single threaded user. Even in Java there are synchronized and non-synchronized versions of collections. IMHO, the protection should happen in your app, and basic collections do not have to be thread safe. Sven #shuffle does not use CollectionmutexForPicking as other users of #randomForPicking demonstrate. This can lead to race conditions (found in our application). In addition, there are now #shuffle, #shuffled, #shuffleBy: and #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers that. This is very confusing. I propose a fix where #shuffled and #shuffledBy: are renamed to #copyShuffle and #copyShuffledBy: and moved to the copying protocol. #shuffle and #copyShuffle will use the mutex to prevent race conditions.
Re: [Pharo-dev] Use pharo users mailing list
I like that idea. At least some of the questions on the users list are not even Pharo specific but regard Smalltalk in general. Those need not be answered by us but can be answered by anyone with a Smalltalk background, be it VW, VA, Squeak… On the other hand (I'm not sure about this, since I don't read the users list) there might be topics like job offers / searches, or more general discussions on that list and moving to SO would kill those (one could argue that such topics would be more suitable on pharo-dev…) since SO is strictly question and answer orientated. Another argument for closing the users list: Marcus wouldn't have to save two lists the next time the servers go down :) Cheers, Max On 23.09.2013, at 08:48, kilon theki...@yahoo.co.uk wrote: Here is a radical suggestion you probably don't want to hear. Close down Pharo users mailing list, redirect everyone to stackoverflow. Consider stackoverflow is THE forum for coding, I cant think of a better place to ask questions for smalltalk and pharo , rarely questions left unanswered there and I wont even start to discuss how cool of a website it is. Oh and a minor bonus is a huge advertisement for pharo. But then take my idea with a grain of salt, I don't like mailing lists :) Thank god for forum.world.st :D Norbert Hartl wrote We should use the pharo users mailing list more often. Imagine there are people only subscribed to the users list. They can't see a lot of interesting posts and the users list does not appear to be very lively. At least half of the posts here in the last days I would like to see on the users list. So if your post is not really about the development of pharo or is not a problem with pharo core (external package discussions belong IMHO to the users list as well) then consider to post to the users list. Everyone you like to reach is subscribed there, too. Norbert -- View this message in context: http://forum.world.st/Use-pharo-users-mailing-list-tp4709698p4709702.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] 11635: Race condition in SequenceableCollectionshuffle
Sven suggested posting this on the list for discussion, so here you go: Maybe this should be discussed on the list, your are going to break API. Note that there is also #sort and #sorted with similar copy behavior. Also, I am not sure that basic operations should use mutexes to protect themselves by default: there is a cost when you are a single threaded user. Even in Java there are synchronized and non-synchronized versions of collections. IMHO, the protection should happen in your app, and basic collections do not have to be thread safe. Sven #shuffle does not use CollectionmutexForPicking as other users of #randomForPicking demonstrate. This can lead to race conditions (found in our application). In addition, there are now #shuffle, #shuffled, #shuffleBy: and #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers that. This is very confusing. I propose a fix where #shuffled and #shuffledBy: are renamed to #copyShuffle and #copyShuffledBy: and moved to the copying protocol. #shuffle and #copyShuffle will use the mutex to prevent race conditions.
Re: [Pharo-dev] SHA1 changed ??
Hi Sorry, I was on holidays and didn't see this. On 23.09.2013, at 20:45, Sven Van Caekenberghe s...@stfx.eu wrote: https://pharo.fogbugz.com/f/cases/11664/SHA1-hashStream-should-return-a-ByteArray-of-size-20 with slice On 13 Sep 2013, at 15:38, Sven Van Caekenberghe s...@stfx.eu wrote: Bump. Max ? On 30 Aug 2013, at 13:52, Sven Van Caekenberghe s...@stfx.eu wrote: On 30 Aug 2013, at 13:39, Marcus Denker marcus.den...@inria.fr wrote: On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano esteba...@gmail.com wrote: I'm not aware of such a change... this is probably an error/side effect of something else. This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the image… Yes that's true. Those two classes were nearly identical. I resolved differences by using the latest method versions of differing methods. Therefore it might well be that I changed that method to the way it is today because the current version is the one with the younger timestamp (I think the changes all came from Stef). Cheers, Max https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations I want to wait for Max to respond/explain. But according to http://en.wikipedia.org/wiki/Sha1 SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long. The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash. Esteban On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Max, Why was the contract of SHA1hashStream: changed ? It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption. MD5 hashMessage: 'foo'. #[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216] SHA1 hashMessage: 'foo'. 68123873083688143418383284816464454849230703155 It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions. Can you please explain ? Sven
Re: [Pharo-dev] Fuel API bug
Done. Name: ConfigurationOfFuel-MaxLeske.207 Author: MaxLeske Time: 4 August 2013, 4:49:17.037 pm UUID: 5cc59075-e365-4a58-a20b-22e40b2b70c9 Ancestors: ConfigurationOfFuel-MartinDias.206 * created new version 1.9.2 for development * pointed development to 1.9.2 * includes changes Camillo wanted to introduce into 1.9.1 (DateAndTime fix) On 04.08.2013, at 16:35, Max Leske maxle...@gmail.com wrote: Yeah, no problem. I'll get on it right away. Max On 04.08.2013, at 16:10, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys can you rename this method? on: aCollectionOrStream do: aBlock Evaluates a block with a new stream based on the collection or stream. Answers the result of the block evaluation. Follows the style of FileStreamfileNamed:do:. | aStream | aStream := self on: aCollectionOrStream. [ ^ aBlock value: aStream ] ensure: [ aStream close ] Please do not use on:do: for something that is not about exception (and announcements). It is too confusing and refactor after. Stef
Re: [Pharo-dev] New PharoVM built
I'm using the US international layout. Not working: - delete button - diaeresis (for umlauts); option + u (+ any character that accepts diaeresis) - probably more (didn't go through more) On 01.08.2013, at 11:47, Igor Stasenko siguc...@gmail.com wrote: On 1 August 2013 10:27, p...@highoctane.be p...@highoctane.be wrote: Keyboard: Belgian french Key combination that doesn't work: hit the caret key... hit fn-Backspace... both things pretty standard. ah, i think its same as for me, when i found my Delete key stop working. Phil On Thu, Aug 1, 2013 at 9:14 AM, Esteban Lorenzano esteba...@gmail.com wrote: still works for me... looks like a keyboard distribution problem, we'll check (bah, Guille will do it :) soon :) can you send which keyboard layour do you use? and exactly which key combinations are you trying? thanks, Esteban On Aug 1, 2013, at 12:01 AM, p...@highoctane.be wrote: Same for me with the backspace. Caret impossible to type ( ^ ... needless to say, bad...) Umlauts and ~ not working either. Smalltalk vm version 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Jul 19 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Jul 19 2013 git://gitorious.org/cogvm/blessed.git Commit: 746b609f0323a8db5de2f1aa36f3eed07e312dfe Date: 2013-07-19 13:54:47 +0200 By: Esteban Lorenzano esteba...@gmail.com Jenkins build #14619 ' erfeklfefeefe⌦⌦ferfe The things with xes is what I get from copy/pasting the string. 'aze⌦⌦⌦uiop' asByteArray #[0 0 0 97 0 0 0 122 0 0 0 101 0 0 35 38 0 0 35 38 0 0 35 38 0 0 0 117 0 0 0 105 0 0 0 111 0 0 0 112] Phil On Wed, Jul 31, 2013 at 10:49 PM, Max Leske maxle...@gmail.com wrote: I'm seeing the same with latest 3.0. The problem starts occuring as of build 165. 164 is still ok. On 31.07.2013, at 18:31, Igor Stasenko siguc...@gmail.com wrote: On 31 July 2013 17:55, Max Leske maxle...@gmail.com wrote: On 31.07.2013, at 17:44, Esteban Lorenzano esteba...@gmail.com wrote: works for me. In which platform are you testing? OS X 10.8.4, 64 bit, Pharo 1.3 can you try it in 3.0 image? On Jul 31, 2013, at 5:32 PM, Max Leske maxle...@gmail.com wrote: There seems to be an issue relating to the keyboard. I can't type any umlauts (option + u) and the delete button produces a question mark. Max On 31.07.2013, at 16:59, Max Leske maxle...@gmail.com wrote: Will do. Thanks! On 31.07.2013, at 16:46, Esteban Lorenzano esteba...@gmail.com wrote: Hi, I builded new versions of the vm, integrating latest changes from Eliot. This integration should fix some issues, between them the annoying SmallInteger problem. You can find it here: wget -O- get.pharo.org/20+vmLatest or directly here: http://files.pharo.org/vm/pharo/ (choose the one that fits the best for you, always the latest) can you download and check? thanks, Esteban -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] New PharoVM built
Will do. Thanks! On 31.07.2013, at 16:46, Esteban Lorenzano esteba...@gmail.com wrote: Hi, I builded new versions of the vm, integrating latest changes from Eliot. This integration should fix some issues, between them the annoying SmallInteger problem. You can find it here: wget -O- get.pharo.org/20+vmLatest or directly here: http://files.pharo.org/vm/pharo/ (choose the one that fits the best for you, always the latest) can you download and check? thanks, Esteban
Re: [Pharo-dev] New PharoVM built
There seems to be an issue relating to the keyboard. I can't type any umlauts (option + u) and the delete button produces a question mark. Max On 31.07.2013, at 16:59, Max Leske maxle...@gmail.com wrote: Will do. Thanks! On 31.07.2013, at 16:46, Esteban Lorenzano esteba...@gmail.com wrote: Hi, I builded new versions of the vm, integrating latest changes from Eliot. This integration should fix some issues, between them the annoying SmallInteger problem. You can find it here: wget -O- get.pharo.org/20+vmLatest or directly here: http://files.pharo.org/vm/pharo/ (choose the one that fits the best for you, always the latest) can you download and check? thanks, Esteban
[Pharo-dev] rackincloude seaside hosting
rackincloud.com offers seaside hosting. I find that really cool but there's absolutely no information on who they are and how much hosting costs. Can anyone shed some light please? Cheers, Max
Re: [Pharo-dev] About abuse of inheritance
Great answer Igor! I'm curious about Doru's response :) On 19.07.2013, at 17:31, Igor Stasenko siguc...@gmail.com wrote: So, on your place, if you really need a lot of classes with announcer capabilities, you can do it like that: Object subclass: #ObjectWithAnnouncer instvars: 'announcer' then may implement same protocol as in Announcer in it, which will simply delegate to announcer ivar. And i bet, you don't want to expose full Announcer protocol there, while probably you may want to implement some convenience protocols, which Announcer lacking. So, at the end by subclassing from ObjectWithAnnouncer you will be reusing its capabilities in each and every subclass of it, but by delegating real job, you are free from worrying about dealing with implementation detail and exposing unwanted state/protocols to its users. Another aspect of it, is when i see: ObjectWithAnnouncer subclass: #MyDomainObject it tells me, aha.. so some (at least this one) of his domain objects having announcers, and the valid protocols is defined in ObjectWithAnnouncer. but when i see Announcer subclass: #MyDomainObject i starting to be uncertain: is Announcer private there or public? can i send messages like #basicSubscribe: to your domain object and expect that it will be handled correctly? Or do i allowed to subscribe directly at all, because maybe domain object has some specific protocol(s) and ways to do that.. Every such question and uncertainty for coder means more time, more errors, and less productivity. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] should:raise:description:
On 09.07.2013, at 23:28, Camillo Bruni camillobr...@gmail.com wrote: On 2013-07-09, at 21:23, Frank Shearar frank.shea...@gmail.com wrote: On 9 July 2013 19:45, Camillo Bruni camillobr...@gmail.com wrote: I continue my rant with should:raise:description: a) self should: [ Error signal: 'error message' ] raise: Halt description: 'message'. b) self should: [ 1 + 2 ] raise: Halt description: 'message'. In the first case you do not get the 'message' but 'error message'. In the second case you get the 'message'. Does the description make sense in this case? 1. if you signal Halt everything is fine 2. Every other case is a failure 3. In case a) an internal failure happens so the test fails anyway, fine, but no description 4. A strange? case where the tests actually DO pass but we nevertheless want to print a description. Can anybody give me a convincing case for 4? Sorry, after this I will stop :D In case (a) I would actually expect to see something like: message. Unexpected Error raised: 'error message'. In case (b) I'd want to see message: no Halt raised I can't think of why you would want a description for a success case, so #4 just seems weird! exactly! :) I agree on that ;). Now the question is on how to properly fix this for debugging. Since you actually want to debug on the unexpected Exception in case a)... YE!! That's about the thing I hate the most about SUnit: if a testrun fails because #should: fails, the signaler context is gone. That's SO ANNYOING! I'll check my magic box..
Re: [Pharo-dev] Issue-5468: Extract CRC code - NativeBoost?
On 09.07.2013, at 09:06, Stéphane Ducasse stephane.duca...@inria.fr wrote: Max I added you to the Pharo team. Great, thanks. So now you should be able to commit to the inbox (soon it should be fixed). Then I tried to merge (I read the beginning ogf the article and this is a nice article) but I could not because Fuel-marcus766 is not found. May be my image is not recent enough. Fuel-MarcusDenker.766 is the default Fuel version in the latest 3.0 (curl get.pharo.org/30 | bash). I did all my work in there. I should probably add a repository but I could not find it. As promised (a very long while ago) I moved all the checksum code to a dedicated hiearchy (see https://pharo.fogbugz.com/default.asp?5468). The thing I'm most proud of is the CRC class which implements Ross Williams's RockSoft parameterized CRC caculation model (http://www.ross.net/crc/). Currently there are still two plugin primitives (used by the Compression package) which I simply moved to the new Checksum hierarchy. When I originally wrote the CRC class I wasn't aware of NativeBoost. Today I saw that there are two methods NativeBoost offers for crc32 calculations. I don't have time to look in to that but I just wanted to put the idea out there that with the checksum code now all in one place, we might be able to perform all checksum calculations through NB (and get rid of the ZipPlugin :) ). Any thoughts? Cheers, Max
Re: [Pharo-dev] the return of the strange methods
On 09.07.2013, at 17:42, Clément Bera bera.clem...@gmail.com wrote: They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ some strange code ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange' Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ? +1 2013/7/9 Frank Shearar frank.shea...@gmail.com On 9 July 2013 16:24, Camillo Bruni camillobr...@gmail.com wrote: Survey: who uses the following methods? and if yes why? - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString I honestly cannot wrap my head around these two methods. They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it! frank
[Pharo-dev] Issue-5468: Extract CRC code - NativeBoost?
As promised (a very long while ago) I moved all the checksum code to a dedicated hiearchy (see https://pharo.fogbugz.com/default.asp?5468). The thing I'm most proud of is the CRC class which implements Ross Williams's RockSoft parameterized CRC caculation model (http://www.ross.net/crc/). Currently there are still two plugin primitives (used by the Compression package) which I simply moved to the new Checksum hierarchy. When I originally wrote the CRC class I wasn't aware of NativeBoost. Today I saw that there are two methods NativeBoost offers for crc32 calculations. I don't have time to look in to that but I just wanted to put the idea out there that with the checksum code now all in one place, we might be able to perform all checksum calculations through NB (and get rid of the ZipPlugin :) ). Any thoughts? Cheers, Max
Re: [Pharo-dev] Possible PharoVM bug (wrong object on stack top)
I've opened a new issue for this bug: https://pharo.fogbugz.com/default.asp?11130 It has a couple of methods attached (together with their byte codes) that exhibited the problem. Cheers, Max On 27.06.2013, at 20:44, Igor Stasenko siguc...@gmail.com wrote: What i find fun with this bug, that it is one that is just annoying (you just get a DNU, then you restart and it works). Comparing to hard VM crash we experienced before... :) On 27 June 2013 20:23, p...@highoctane.be p...@highoctane.be wrote: I do have that issue often when loading my devstack configuration on Pharo 2.0 (as in http://www.smalltalkhub.com/#!/~philippeback/HOWebStack) Doing everything again fixes the problem but fingers crossed are required. It is a really annoying bug indeed. Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Thu, Jun 27, 2013 at 3:22 PM, Igor Stasenko siguc...@gmail.com wrote: On 27 June 2013 14:13, Max Leske maxle...@gmail.com wrote: Hi I've been seeing a particular bug that I can only see when using the PharoVM and I was wondering if anybody else has been having the same issue. Under certain condition, a debugger will open displaying SmallInteger does not understand some message. The stack top contains an integer (something of the form 138402, not sure how many digits), which explains the message. However, the situation actually looks like this: htmil anchor id: 'foo'; … In this example, the error would be SmallInteger does not understand #id:. So the stack top contains an integer instead of the receiver. Restarting the execution of the method and proceeding fixes the problem. I think I've seen that (using seaside), a new session will trigger the bug again. Apart from Seaside, I've also seen the same problem when loading Roberto Minelli's DevFlow into a Pharo 2.0 image. The debugger will open on a Metacello method. VM: latest PharoVM image: latest 2.0 try this config: http://smalltalkhub.com/#!/~RobertoMinelli/DevFlow with ConfigurationOfDevFlow loadDevelopment Has anybody else encountered this? yes, couple months ago we had this issue. It looks like it doesn't likes some bytecode sequence (which causing this).. and this sequence is not appears that often. If i remember Esteban said that changing compiler optimizations flags fixed it.. but perhaps not on platform , you running on? Cheers, Max -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Abbreviations
I agree wholeheartedly! I still believe in (mostly) self documenting code and that cannot be achieved by using abbreviations. Max On 04.07.2013, at 12:52, Torsten Bergmann asta...@gmx.de wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
Re: [Pharo-dev] Abbreviations
On 04.07.2013, at 13:09, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ... My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit … zealous. Agreed. There are conventional terms that can (and maybe should) be abbreviated. But in general I'm against abbreviations. Simple abbreviations, like env, rather than using the full word, I have much less empathy for. Cheers, Henry
Re: [Pharo-dev] anonymous issue report
I didn't report it but here's a usecase: suppose you have a collection of objects and they might include nil. Now, if you want to do this: myCollection do: [ :element | element class allSubclassesDo: #value ] ] then you'll get an exception when element is nil. superclass == nil On 02.07.2013, at 14:23, Camillo Bruni camillobr...@gmail.com wrote: Who reported UndefinedObject should implement #allSuperclassesDo: ? Could you please give an example on how to reproduce this?
[Pharo-dev] Possible PharoVM bug (wrong object on stack top)
Hi I've been seeing a particular bug that I can only see when using the PharoVM and I was wondering if anybody else has been having the same issue. Under certain condition, a debugger will open displaying SmallInteger does not understand some message. The stack top contains an integer (something of the form 138402, not sure how many digits), which explains the message. However, the situation actually looks like this: htmil anchor id: 'foo'; … In this example, the error would be SmallInteger does not understand #id:. So the stack top contains an integer instead of the receiver. Restarting the execution of the method and proceeding fixes the problem. I think I've seen that (using seaside), a new session will trigger the bug again. Apart from Seaside, I've also seen the same problem when loading Roberto Minelli's DevFlow into a Pharo 2.0 image. The debugger will open on a Metacello method. VM: latest PharoVM image: latest 2.0 try this config: http://smalltalkhub.com/#!/~RobertoMinelli/DevFlow with ConfigurationOfDevFlow loadDevelopment Has anybody else encountered this? Cheers, Max
Re: [Pharo-dev] Possible PharoVM bug (wrong object on stack top)
Thanks guys. So Esteban, do you need more cases? I can provide some if you want me to. Cheers, Max On 27.06.2013, at 15:34, Esteban Lorenzano esteba...@gmail.com wrote: On Jun 27, 2013, at 3:22 PM, Igor Stasenko siguc...@gmail.com wrote: On 27 June 2013 14:13, Max Leske maxle...@gmail.com wrote: Hi I've been seeing a particular bug that I can only see when using the PharoVM and I was wondering if anybody else has been having the same issue. Under certain condition, a debugger will open displaying SmallInteger does not understand some message. The stack top contains an integer (something of the form 138402, not sure how many digits), which explains the message. However, the situation actually looks like this: htmil anchor id: 'foo'; … In this example, the error would be SmallInteger does not understand #id:. So the stack top contains an integer instead of the receiver. Restarting the execution of the method and proceeding fixes the problem. I think I've seen that (using seaside), a new session will trigger the bug again. Apart from Seaside, I've also seen the same problem when loading Roberto Minelli's DevFlow into a Pharo 2.0 image. The debugger will open on a Metacello method. VM: latest PharoVM image: latest 2.0 try this config: http://smalltalkhub.com/#!/~RobertoMinelli/DevFlow with ConfigurationOfDevFlow loadDevelopment Has anybody else encountered this? yes, couple months ago we had this issue. It looks like it doesn't likes some bytecode sequence (which causing this).. and this sequence is not appears that often. If i remember Esteban said that changing compiler optimizations flags fixed it.. but perhaps not on platform , you running on? no, I didn't said that :) I still don't know how to fix this... I can workaround the problem, but the real problem is still there. see: https://pharo.fogbugz.com/f/cases/10395 for an explanation on how to workaround the issue. cheers, Esteban Cheers, Max -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Possible PharoVM bug (wrong object on stack top)
OK. I'll collect some cases and post them on the FogBugz issue. On 27.06.2013, at 16:06, Guillermo Polito guillermopol...@gmail.com wrote: It would be good to have a simple way to reproduce it and make a test for it. I tried that last week but I wasn't able to reproduce it :(. In any case, the problem is with the JIT. On a StackVM we don't have the problem. On Thu, Jun 27, 2013 at 4:00 PM, Max Leske maxle...@gmail.com wrote: Thanks guys. So Esteban, do you need more cases? I can provide some if you want me to. Cheers, Max On 27.06.2013, at 15:34, Esteban Lorenzano esteba...@gmail.com wrote: On Jun 27, 2013, at 3:22 PM, Igor Stasenko siguc...@gmail.com wrote: On 27 June 2013 14:13, Max Leske maxle...@gmail.com wrote: Hi I've been seeing a particular bug that I can only see when using the PharoVM and I was wondering if anybody else has been having the same issue. Under certain condition, a debugger will open displaying SmallInteger does not understand some message. The stack top contains an integer (something of the form 138402, not sure how many digits), which explains the message. However, the situation actually looks like this: htmil anchor id: 'foo'; … In this example, the error would be SmallInteger does not understand #id:. So the stack top contains an integer instead of the receiver. Restarting the execution of the method and proceeding fixes the problem. I think I've seen that (using seaside), a new session will trigger the bug again. Apart from Seaside, I've also seen the same problem when loading Roberto Minelli's DevFlow into a Pharo 2.0 image. The debugger will open on a Metacello method. VM: latest PharoVM image: latest 2.0 try this config: http://smalltalkhub.com/#!/~RobertoMinelli/DevFlow with ConfigurationOfDevFlow loadDevelopment Has anybody else encountered this? yes, couple months ago we had this issue. It looks like it doesn't likes some bytecode sequence (which causing this).. and this sequence is not appears that often. If i remember Esteban said that changing compiler optimizations flags fixed it.. but perhaps not on platform , you running on? no, I didn't said that :) I still don't know how to fix this... I can workaround the problem, but the real problem is still there. see: https://pharo.fogbugz.com/f/cases/10395 for an explanation on how to workaround the issue. cheers, Esteban Cheers, Max -- Best regards, Igor Stasenko.
[Pharo-dev] Pharo 2.0: Review for Fuel fix integration required
Hi guys I created a new Fuel version that includes an important fix (in my opinion). That fix should be integrated into Pharo 2.0 (in my opinion); here's the integration request: https://pharo.fogbugz.com/default.asp?10730 Summary of the change: Changes in the serialized graph during serialization do no longer affect serialization, i.e. the graph serialized it the graph as encountered during analysis. This fix is important for the Fuel out stack feature in Pharo2.0 because of contexts that can reference processes (e.g. with Seaside). Since Marcus does not have the capacity to review everything in the inbox, I need one or two poeple to look at the request and green light it. Side note: we need more people to review changes. Simply assigning everything to Marcus doesn't seem to solve this problem :) Thanks for your time. Cheers, Max
[Pharo-dev] Fwd: Vm-dev Digest, Vol 83, Issue 46
Begin forwarded message: On Fri, May 31, 2013 at 1:11 PM, Eliot Miranda eliot.mira...@gmail.comwrote: On Fri, May 31, 2013 at 12:54 AM, Max Leske maxle...@gmail.com wrote: Bump. Doesn't anybody feel that corrupt blocks are a problem? IMHO that's something that should *never* happen. But what's happening here is that the Fuel serializer is allowing the serialization of blocks without serializing their outer context and method, and later the reconstruction of blocks against the *wrong* version of a method. This is a Fuel bug. IMO the right solution is for Fuel to serialize the method of the block, and on reconstruction replace the reconstructed method with the method in the system iff the reconstructed method is the same as that in the system, but substitute the recinstructed method if it differs from the system's version (or of course if the system;s version is missing). this mimics the system's behaviour with unbound methods, where e.g. a block holds onto a method and the code of a class is recompiled, resulting iun that block holding onto an unbound method. Sorry, without serializing their outer context and method is wrong; without serializing their method
Re: [Pharo-dev] Release Artefact 1.0, the PDF framework
Awesome guys! I'll have to take a look soon. Max On 31.05.2013, at 16:00, Damien Cassou damien.cas...@gmail.com wrote: Images are automatically built by a continuous integration job: https://ci.inria.fr/pharo-contribution/job/Artefact/. On Fri, May 31, 2013 at 3:30 PM, Guillaume Larcheveque guillaume.larcheve...@gmail.com wrote: We are proud to announce that Artefact is available in 1.0 version. You can download it from: http://smalltalkhub.com/#!/~RMoD/Artefact Artefact is a framework to generate PDF documents. It is fully written in Smalltalk and doesn't require any native library. Artefact is light, platform independant and offer to users a high level of abstraction in order to easily creating PDF documents. * completely written in Smalltalk (and only Smalltalk), * complete freedom about the order of creation for pages, elements... (no need to follow the document order) * multi format and orientation for pages * page composition based on reusables PDF elements, * extensibility by offering a composition standard to create your own high level elements * styleSheet that can be reused in many documents and avoid wasting time and place with duplication * image support with the JPEG format * pre-defined high level elements like datagrid * support PDF compression to produce compact files A basic documentation is available in the help browser. Many examples are implemented in the PDFDemos class. -- Olivier Auverlot and Guillaume Larcheveque -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] [ANN]: ValidationRevisited (alpha)
I love the music you used in your screencast :D Sounds a bit like a telephone waiting line On 30.05.2013, at 08:52, stephane ducasse stephane.duca...@free.fr wrote: I started to read the chapter to understand. Stef stephane ducasse wrote show us how you specify that? It's a simple Spec UI, receiving announcements from the domain object. Whenever the model changes, the UI receives: modelChanged: anAnnouncement failureList items: model validate failures. #validate is the main entry point for the framework. You can call this on any domain object and the validation rules will be run. Under the hood are specialized SUnit classes. Here (on Nabble) is a screenshot of the validator class, a specialized TestCase which holds the rules for the object in the screencast: http://forum.world.st/file/n4690694/Screen_Shot_2013-05-29_at_5.37.12_PM.png The really cool thing which is not shown in the video is that the failures are real objects which hold the domain object, the property that failed (called an 'aspect'), and the description shown in the UI. So you could do a lot more than show the description... - Cheers, Sean -- View this message in context: http://forum.world.st/ANN-ValidationRevisited-alpha-tp4690680p4690694.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Fwd: [Pharo-fuel] Corrupt BlockClosure
Begin forwarded message: From: roberto.mine...@usi.ch roberto.mine...@usi.ch Subject: Re: [Pharo-fuel] [Pharo-dev] Corrupt BlockClosure Date: 24. Mai 2013 08:10:19 MESZ To: The Fuel Project pharo-f...@lists.gforge.inria.fr Reply-To: The Fuel Project pharo-f...@lists.gforge.inria.fr Hi, Thanks all of you for interest ;) On May 24, 2013, at 7:15 AM, Max Leske maxle...@gmail.com wrote: I played around with reverting the method and serializing but that doesn't change anything (the existing BlockClosure is obviously not modified). Then I thought that maybe the method was changed during a running DFSession but still couldn't reproduce. Me neither!! @Roberto Can you tell us anything about what you did befor / during / after running your session? Nope. Unfortunately I've a couple of broken sessions I cannot serialize because of that bug.. But all of them refers sooner or later to the DFSession#numberOfMethodCalls method. Dunno why. @Roberto Is it possible to reproduce the stack with a new session? Or did this only happen once? I have no clue how to reproduce, but it did not happen only once. As I said, there are 3/4 sessions I couldn't export due to this SubscriptOutOfBounds. Cheers, Roby On 24.05.2013, at 06:44, Max Leske maxle...@gmail.com wrote: On 23.05.2013, at 22:58, Camille Teruel camille.ter...@gmail.com wrote: Hi, This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: theBlock instVar: 2 put: 43. The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession#numberOfMethodCalls), but I don't know why. Would it help to recompile the method? I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? No, there was never a materialization of that session. Camille On 23 mai 2013, at 21:02, Max Leske wrote: Hi Marcus Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. To see the stack, right click on the only entry in the right window and click export session. You'll find the corrupt BlockClosure at BlockClosurefuelAccept: @Roberto Is it possible to reproduce the stack with a new session? Or did this only happen once? Cheers, Max Begin forwarded message: From: Mariano Martinez Peck marianop...@gmail.com Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 Date: 23. Mai 2013 14:23:45 MESZ To: The Fuel Project pharo-f...@lists.gforge.inria.fr Reply-To: The Fuel Project pharo-f...@lists.gforge.inria.fr Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) Thanks! On Thu, May 23, 2013 at 8:41 AM, Max Leske maxle...@gmail.com wrote: What's the compiled method? Is it a special one? Which selector in which class? Max On 23.05.2013, at 12:45, roberto.mine...@usi.ch roberto.mine...@usi.ch wrote: Hi, While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns error in printString: evaluate self printString to debug) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. Thanks in advance, Roby # STACK#1 ### ### CompiledMethod(Object)errorSubscriptBounds: CompiledMethod(Object)at: InstructionStreaminterpretNextInstructionFor: CompiledMethodabstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... BlockClosureon:do: CompiledMethodabstractBytecodeMessageAt: BlockClosureblockCreationBytecodeMessage BlockClosureendPC
Re: [Pharo-dev] Corrupt BlockClosure
On 23.05.2013, at 22:58, Camille Teruel camille.ter...@gmail.com wrote: Hi, This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: theBlock instVar: 2 put: 43. The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession#numberOfMethodCalls), but I don't know why. Would it help to recompile the method? I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? No, there was never a materialization of that session. Camille On 23 mai 2013, at 21:02, Max Leske wrote: Hi Marcus Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. To see the stack, right click on the only entry in the right window and click export session. You'll find the corrupt BlockClosure at BlockClosurefuelAccept: @Roberto Is it possible to reproduce the stack with a new session? Or did this only happen once? Cheers, Max Begin forwarded message: From: Mariano Martinez Peck marianop...@gmail.com Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 Date: 23. Mai 2013 14:23:45 MESZ To: The Fuel Project pharo-f...@lists.gforge.inria.fr Reply-To: The Fuel Project pharo-f...@lists.gforge.inria.fr Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) Thanks! On Thu, May 23, 2013 at 8:41 AM, Max Leske maxle...@gmail.com wrote: What's the compiled method? Is it a special one? Which selector in which class? Max On 23.05.2013, at 12:45, roberto.mine...@usi.ch roberto.mine...@usi.ch wrote: Hi, While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns error in printString: evaluate self printString to debug) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. Thanks in advance, Roby # STACK#1 ### ### CompiledMethod(Object)errorSubscriptBounds: CompiledMethod(Object)at: InstructionStreaminterpretNextInstructionFor: CompiledMethodabstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... BlockClosureon:do: CompiledMethodabstractBytecodeMessageAt: BlockClosureblockCreationBytecodeMessage BlockClosureendPC BlockClosureabstractBytecodeMessagesDo: BlockClosureisClean BlockClosureshouldBeSubstitutedByCleanCopy BlockClosurefuelAccept: FLFullGeneralMapper(FLLightGeneralMapper)mapAndTrace: FLFullGlobalMappermapAndTrace: in Block: [(anObject class == CompiledMethod... FLLargeIdentityDictionaryat:ifAbsent: FLFullGlobalMappermapAndTrace: FLPluggableSubstitutionMappermapAndTrace: FLPluggableSubstitutionMappermapAndTrace: FLAnalysismapAndTrace: FLAnalysisrun FLAnalyzersetDefaultAnalysis in Block: [:anObject | (FLAnalysis... FLAnalyzeranalysisFor: FLSerializationanalysisStep FLSerializationrun DFSerializer(FLSerializer)setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... DFSerializer(FLSerializer)serialize:on: in Block: [:anEncoder | ... FLEncoder classon:globalEnvironment:do: in Block: [aBlock value: anEncoder] BlockClosureensure: FLEncoder classon:globalEnvironment:do: DFSerializer(FLSerializer)serialize:on: # STACK#2 ### Decompiler(Object)error
Re: [Pharo-dev] Corrupt BlockClosure
I played around with reverting the method and serializing but that doesn't change anything (the existing BlockClosure is obviously not modified). Then I thought that maybe the method was changed during a running DFSession but still couldn't reproduce. @Roberto Can you tell us anything about what you did befor / during / after running your session? On 24.05.2013, at 06:44, Max Leske maxle...@gmail.com wrote: On 23.05.2013, at 22:58, Camille Teruel camille.ter...@gmail.com wrote: Hi, This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: theBlock instVar: 2 put: 43. The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession#numberOfMethodCalls), but I don't know why. Would it help to recompile the method? I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? No, there was never a materialization of that session. Camille On 23 mai 2013, at 21:02, Max Leske wrote: Hi Marcus Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. To see the stack, right click on the only entry in the right window and click export session. You'll find the corrupt BlockClosure at BlockClosurefuelAccept: @Roberto Is it possible to reproduce the stack with a new session? Or did this only happen once? Cheers, Max Begin forwarded message: From: Mariano Martinez Peck marianop...@gmail.com Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 Date: 23. Mai 2013 14:23:45 MESZ To: The Fuel Project pharo-f...@lists.gforge.inria.fr Reply-To: The Fuel Project pharo-f...@lists.gforge.inria.fr Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) Thanks! On Thu, May 23, 2013 at 8:41 AM, Max Leske maxle...@gmail.com wrote: What's the compiled method? Is it a special one? Which selector in which class? Max On 23.05.2013, at 12:45, roberto.mine...@usi.ch roberto.mine...@usi.ch wrote: Hi, While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns error in printString: evaluate self printString to debug) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. Thanks in advance, Roby # STACK#1 ### ### CompiledMethod(Object)errorSubscriptBounds: CompiledMethod(Object)at: InstructionStreaminterpretNextInstructionFor: CompiledMethodabstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... BlockClosureon:do: CompiledMethodabstractBytecodeMessageAt: BlockClosureblockCreationBytecodeMessage BlockClosureendPC BlockClosureabstractBytecodeMessagesDo: BlockClosureisClean BlockClosureshouldBeSubstitutedByCleanCopy BlockClosurefuelAccept: FLFullGeneralMapper(FLLightGeneralMapper)mapAndTrace: FLFullGlobalMappermapAndTrace: in Block: [(anObject class == CompiledMethod... FLLargeIdentityDictionaryat:ifAbsent: FLFullGlobalMappermapAndTrace: FLPluggableSubstitutionMappermapAndTrace: FLPluggableSubstitutionMappermapAndTrace: FLAnalysismapAndTrace: FLAnalysisrun FLAnalyzersetDefaultAnalysis in Block: [:anObject | (FLAnalysis... FLAnalyzeranalysisFor: FLSerializationanalysisStep FLSerializationrun DFSerializer(FLSerializer)setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... DFSerializer(FLSerializer)serialize:on: in Block: [:anEncoder | ... FLEncoder classon:globalEnvironment:do: in Block: [aBlock value: anEncoder
Re: [Pharo-dev] Messy Configurations
+100! On 22.05.2013, at 17:53, Camillo Bruni camillobr...@gmail.com wrote: I recently spent some time to revise how to write Metacello Configurations. Observation: - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser. Solution: = - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it What do you think?
Re: [Pharo-dev] (Identity)Dictionary benchmarks
On 21.05.2013, at 10:14, Sven Van Caekenberghe s...@stfx.eu wrote: On 21 May 2013, at 09:59, Max Leske maxle...@gmail.com wrote: 3. SmallIntegeridentityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). Yeah, SmallInteger#hashMultiply looks weird and complicated. Probably some attempt at distributing keys better. That's exactly what I gathered from the issues I looked through on FogBugz. But like you say: if #hash can return self, why would #identityHash not do the same ? But I am no hashing expert...
Re: [Pharo-dev] WhatsUp from: 2013-05-20 until: 2013-05-31
On 21.05.2013, at 10:01, Sven Van Caekenberghe s...@stfx.eu wrote: Max, On 21 May 2013, at 09:43, Max Leske maxle...@gmail.com wrote: Not sure if this is related, but my FileSystem-Git build for 2.0 broke this morning with a Zn stack trace (bad gateway): https://ci.inria.fr/pharo-contribution/job/FileSystem-Git/PHARO=20,VERSION=development,VM=vm/53/ Assuming you are loading Zn's #bleedingEdge, could you send me the URL you try to access and that fails ? Hm, doesn't seem to be bleeding edge (although is 2.0 dev). The test is fine on my local machine, so perhaps there's something wrong at inria? Here's the incantation: ZnClient new url: aUrl asZnUrl / 'info' / 'refs'; queryAt: 'service' put: 'git-upload-pack'; username: 'admin' password: 'admin'; enforceHttpSuccess: true; streaming: true; get; yourself with url: 'https://git.gitorious.org/gitorious/mainline.git' Thanks Sven. I mean a standalone version of what is happening here ZnClientget GitDumbHTTPProtocol classinitialRequestTo: GitDumbHTTPProtocol classconnectTo: GitAbstractProtocol classurl: GitSmartHTTPProtocolTest(GitAbstractProtocolTest)newProtocol GitSmartHTTPProtocolTest(GitAbstractProtocolTest)testTags GitSmartHTTPProtocolTest(TestCase)performTest If that is possible without giving out credentials. Sven Max On 21.05.2013, at 09:38, Sven Van Caekenberghe s...@stfx.eu wrote: On 21 May 2013, at 09:30, Damien Cassou damien.cas...@gmail.com wrote: - continue working on the configuration (it looks like Zinc has a bug with its handling of PUT requests) Hi Damien, please elaborate, maybe I can help. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Re: [Pharo-dev] [Pharo-fuel] (Identity)Dictionary benchmarks
On 21.05.2013, at 10:58, Camillo Bruni camillobr...@gmail.com wrote:
my random pessimistic comments
a) your benchmarking script sucks! = use SMARK!!
http://smalltalkhub.com/#!/~StefanMarr/SMark
We're fully aware of that :)
b) check my master thesis for a more thorough testing of dictionary,
including a cleaner implementation that defaults to something like a small
dictionary without a special class:
http://scg.unibe.ch/archive/masters/Brun11a.pdf
the optimistic version:
On 2013-05-21, at 09:47, Max Leske m.le...@netstyle.ch wrote:
My coworker performed some interesting benchmarks on the various dictionary
types in Pharo. If you look at the attachments you'll see four things:
1. SmallDictionary and SmallIdentityDictionary are totally useless when it
comes to performance. Unless their existence is somehow justified by saving
space (which might be important for embedded systems) I don't see why we
should keep them around.
yes their usage is not always justified, but be careful what you measure: as
far as I see you only measure addition, no? (sorry again, but that benchmark
brutally sucks, it's so damn hard to read... :P). Iteration and retrieval
have to measure as well, also how the dictionaries behave under key hash
collisions (though I am definitely not defending the small dicts.. :).
2. The special Fuel collections for large numbers of elements could be a
valuable addition to the basic collections
THere is the pluggable key dictionary for that reason already, no? The main
problem is the limited hashes which results in quite some hash collisions for
very large dictionaries.
3. SmallIntegeridentityHash is really slow. Using SmallInteger as keys in
IdentityDictionary is significantly slower than using them in a regular
Dictionary because the identity check is done via #identityHash (#hash
simply answers self).
that is really strange :/
4. Arrays are cool :)
Should I open issues on FogBugz for any of these points? Especially point 3
bothers me because I feel that using a primitive type should be fast under
all circumstances.
You'll find below the benchmark data (collected in 1.4, verified in 2.0) and
the code to run it.
Cheers,
Max
performance.xlsx
performance.xls
--
( comments are variations)
sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190
200 300 400 500 600 700 800 900 1000 ).
sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190
200 300 400 500 600 700 800 900 1000 1500 2000 2500 3000 3500 4000 4500
5000 6000 7000 8000 9000 1 ).
batches := sizes collect: [ :size | size - ((1000 / size) asFloat //
10) ].
batches := sizes collect: [ :size | size - 1 ].
alphabet := Character alphabet.
batches do: [ :a | Transcript tab; show: a key asString ]. Transcript cr.
batches do: [ :a | Transcript tab; show: a value asString ]. Transcript cr.
{ Dictionary. SmallDictionary. IdentityDictionary.
SmallIdentityDictionary. FLLargeIdentityDictionary }
{ Dictionary. IdentityDictionary. FLLargeIdentityDictionary }
{ Array }
do: [ :class |
Smalltalk garbageCollect.
Transcript show: class name.
batches
do: [ :a |
| struct strings iterations |
strings := (1 to: a key) collect: [ :i | i
asString ].
strings := (1 to: a key) collect: [ :i |
String streamContents: [ :s |
20 atRandom timesRepeat: [ s
nextPut: alphabet atRandom ] ] ].
struct := class new.
struct := (class = FLLargeIdentityDictionary
ifTrue: [ class new ]
ifFalse: [ class new: a key ]).
Transcript tab; show: ([
a value timesRepeat: [
1 to: a key do: [ :i | struct
at: (strings at: i) i put: i ] ] ] timeToRun).
strings := nil ]
displayingProgress: class name asString.
Transcript cr. ]
displayingProgress: 'Processing ...'
___
Pharo-fuel mailing list
pharo-f...@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
___
Pharo-fuel mailing list
pharo-f...@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
Re: [Pharo-dev] About the Mailinglist debacle...
Thanks for the effort Markus! On 15.05.2013, at 19:52, Marcus Denker marcus.den...@inria.fr wrote: Hello, So now that everything is working… sorry for the mess. We should have left the gforge infrastructure the last time we had a multi-day problem, not wait till we get it again. I think this will be my new principle: second real problem - I leave. No discussions. We already saw with the jenkins story just how deadly bad infrastructure is. So what happened was that last Tuesday, the lists (all lists of gforge) stopped delivering. Why is not clear, seemingly it was not gforge itself but the upstream servers did not deliver. Whatever. What is clear is that it was completely unclear how long this would take, and that we needed a solution after nearly a week of waiting. So we decided to move the lists. Of course with the old lists down, this was harder than normal (even involved parsing the html to get the subscribers…) but that is not important. Now the problem its hat Mailman does not distinguish between people that unsubscribe, and those turning off delivery. So there where just a lot of people listed with nomail (U), What to do? It was clear that we can't just subscribe lots of people to a list that they *actively* unsubscribed. So the only option was to skip those by - unsubscribing them from the old list - then get the list of subscribers - put that in the new list. The only people that will see a bad effect are those using e.g nabble to read the list. But those would see the new mails, too. The only problem they have is if the want to send. So not *that* of a big deal. It seems that we got quite some false positive subscribers anyway in the form of people who filtered the mails and then with the new list the filter did not work and they suddenly saw mails of a long forgotten list. We even had the case of people who where nomail (U), yet they did get mails delivered. How that can possibly work, I have no clue *at all*. What else is missing (and on my TODO since Sunday/Monday, sorry for not yet acting on it): - lists.pharo.org has an empty page and needs to point to the list of the lists inttead - the archive needs to be moved from the old jenkins. - the (incomplete) archive of the new lists is not working since I put it as public. So… maybe it would have been better to just wait until gforge works again and then move… but it was just far too long already and not clear when it would be working again. Marcus
