Vm-dev May 2011

vm-dev@lists.squeakfoundation.org

36 participants
89 discussions

About insulting developers (Was: Re: [Vm-dev] VM Maker: CMakeVMMaker-StasenkoIgor.104.mcz)
by Igor Stasenko 18 May '11

18 May '11

On 17 May 2011 10:00, Andreas Raab <andreas.raab(a)gmx.de> wrote: > > On 5/17/2011 9:27, Igor Stasenko wrote: >> >> On 16 May 2011 17:16, Andreas Raab<andreas.raab(a)gmx.de> wrote: >>> >>> On 5/16/2011 12:34, squeak-dev-noreply(a)lists.squeakfoundation.org wrote: >>>> >>>> Igor Stasenko uploaded a new version of CMakeVMMaker to project VM >>>> Maker: >>>> http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: CMakeVMMaker-StasenkoIgor.104 >>>> Author: StasenkoIgor >>>> Time: 16 May 2011, 10:33:56 am >>>> UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b >>>> Ancestors: CMakeVMMaker-IgorStasenko.103 >>>> >>>> workaround the MultiByteCrapStream, which converting line endings twice >>>> on >>>> windows. >>>> >>> Do us all a favor and leave out these derogatory comments. They are *not* >>> helpful. >>> >> :) >> Well, i can't resist putting it like that, because i lost like 1 hour >> trying to understand why it was broken again. > > I understand what you mean but the thing you need to learn is that there's a > big difference between a muttered curse and a public comment. A check-in > comment that is being reposted in archived mailing lists is something that > people read. Treating your fellow developers without respect is a great way > of ensuring difficult relationships in the future. Nobody likes being called > names, or derogatory comments about their code, not you, not me, not anyone. > There is no reason to call MultiByteFileStream MultiByteCrapStream other > than an intentional insult to the original author(s). Insulting people in a > public forum is a great way to destroy relationships. Just ask your boss. > I disagree. I do respect the people's energy which they spent implementing all this stuff, because apparently i'm using it every day and it works (most of the times ;). Such strong wording was to point on problem & amount of pain i had with it, but again, nothing to do with my attitude towards author(s) who implemented it. I separating these things and i hope others too. It was i, who were insulted, offended and lost time dealing with this code. So why i can't express myself appropriately to situation? :) Because i tend to say and hear truth about the quality of code (including my own , of course). Seriously, why we should fear to offend someone by calling a crap what is crap? If next day, someone would call my code crap, my first reaction will be to ask - why, where and how to improve that. But not to put that person in black list. Because i value criticism. It helps you to get higher, above your own limits :) -- Best regards, Igor Stasenko AKA sig.

2 3

NetNameResolver localHostAddress returns 0.0.0.0 in FreeBSD
by Gary Dunn 17 May '11

17 May '11

Mantis 7624. Originally reported as an error pulling out a badge. Investigation reveals that the primitive is failing to return the local IP address. <primitive: 'primitiveResolverLocalAddress' module: 'SocketPlugin'> in class NetNameResolver. Works correctly in Win7 and Mac OS X. FreeBSD has a reputation of dealing with network configuration differently than Linux. -- Gary Dunn Honolulu

2 1

VM Maker: VMMaker-dtl.235.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 17 May '11

17 May '11

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.235.mcz ==================== Summary ==================== Name: VMMaker-dtl.235 Author: dtl Time: 16 May 2011, 10:13:04 am UUID: d4f61bb1-70b4-4822-8e56-89ef078e827a Ancestors: VMMaker-dtl.234 Non-functional updates to LargeIntegersPlugin for consistency with oscog branch.

1 0

VM Maker: VMMaker.oscog-dtl.67.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 17 May '11

17 May '11

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker.oscog-dtl.67.mcz ==================== Summary ==================== Name: VMMaker.oscog-dtl.67 Author: dtl Time: 16 May 2011, 9:31 am UUID: 08000000-1508-4e03-1508-4e0314000000 Ancestors: VMMaker-oscog-MarianoMartinezPeck.66 Synchronize with VMMaker-dtl.234 and VMMaker-dtl.233 Mantis 7109: Change Set: LargeIntegersPlugin-SpeedUp-BitShift-Patch-M7109-nice Date: 4 July 2008 Author: nice These are small improvment to speed up LargeIntegersPlugin bitShift: See http://bugs.squeak.org/view.php?id=7109 Mantis 7120: Change Set: Integer-raisedTo-modulo-COGplugin-M7120-nice Date: 12 July 2008 Author: nice This is a LargeInteger plugin extension to compute Montgomery modular multiplication ((a * b ) / (d^n)) \\ m Digit d is set to 256 (LargeIntegers are Byte arrays) n is set to m digitLength. The negated inverse of m modulo 256 has to be provided on input

2 1

VM Maker: VMMaker-dtl.233.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 17 May '11

17 May '11

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.233.mcz ==================== Summary ==================== Name: VMMaker-dtl.233 Author: dtl Time: 15 May 2011, 6:09:52 am UUID: 4b627403-058b-4826-8c7f-74dd0ef6b803 Ancestors: VMMaker-dtl.232 VMMaker 4.4.20 Add LargeInteger plugin extension to compute Montgomery modular multiplication. Reference Mantis 0007120: [ENH] Speed-up raisedTo:modulo: Change Set: Integer-raisedTo-modulo-plugin-M7120-nice Date: 12 July 2008 Author: nice This is a LargeInteger plugin extension to compute Montgomery modular multiplication ((a * b ) / (d^n)) \\ m Digit d is set to 256 (LargeIntegers are Byte arrays) n is set to m digitLength. The negated inverse of m modulo 256 has to be provided on input

2 1

CogVM Benchmarking
by Stefan Marr 16 May '11

16 May '11

Hi Eliot: When exactly is the JIT compilation triggered in Cog? I would like to provide a configuration for the SMark benchmarking framework that ensures that everything got jitted, without doing to much unnecessary warmup. All the benchmark code is implemented in standard methods and executed very similarly to how SUnit works, thus, they are called like 'suite perform: aBenchmarkSelector'. How many iterations should I run the code before I can be sure that it is jitted? From your blog, I assume, it should be jitted after its second execution. (see snippet below) And I supposed a 'Smalltalk garbageCollect' should not interfere with this, and can be safely performed before a timed run? Is there anything else, I should cover in the framework? Any particular heuristics/mechanism that should be taken into account when trying to reach a stable state? What I found on your blog is the following: <<< So a simple way to implement the interpret on single-use policy is to only compile to machine code when finding a method in the first-level method lookup cache. We avoid compiling large methods, which are typically initializers, and rarely performance-critical inner loops, by refusing to compile methods whose number of literals exceeds a limit, settable via the command line that defaults to 60 literals, which excludes a mere 0.3% of methods in my image. >>> Thanks a lot Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

2 2

VM Maker: VMMaker-dtl.234.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 16 May '11

16 May '11

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.234.mcz ==================== Summary ==================== Name: VMMaker-dtl.234 Author: dtl Time: 16 May 2011, 8:04:12 am UUID: 7853b937-c073-45a8-acef-c048681158d2 Ancestors: VMMaker-dtl.233 VMMaker 4.4.21 Add LargeIntegersPlugin bitShift: improvements, auto-pragmas for new methods. Change Set: LargeIntegersPlugin-SpeedUp-BitShift-Patch-M7109-nice Date: 4 July 2008 Author: nice These are small improvment to speed up LargeIntegersPlugin bitShift: See http://bugs.squeak.org/view.php?id=7109

1 0

Re: [Pharo-project] out of memory - cog on windows
by Igor Stasenko 16 May '11

16 May '11

On 10 May 2011 09:34, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I am back with some more input on the matter. We played with it, and found that basically any image that goes beyond something like 200MB limit (or maybe it's the number of objects), will not open on Windows. > > I would need some help on this. Has nobody else hit this wall, or is it that I am doing something wrong? > > One scenario that we used to reproduce the problem looks like this: > 1. Take a Moose image: > http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… > 2. Run: > 1 to: 3 do: [ :i | MooseScripts createModelForConfigurationOfMoose ] > This will basically create some 850000 objects and will get the image to some 400+MB > 3. Save and quit the image > 4. Reopen it > > A ready-made image with the result of this can be found here: > http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip > > This works well on Mac, but on Windows when you reopen the image, you get the out of memory message. > > Cheers, > Doru > > I using latest VMs built by cmake on windows, and everytime i run this image, it opens a 'Space is low' dialog and then image not reacting on anything. VM not crashing however and responds to windows events.. But because UI process is broken an image simply not reacts to anything. I think that the problem is that this dialog are shown at early image startup time, before everything is properly initialized, and because of that UI stalls somewhere. Next things which i tried is to increase a virtual memory limit in sqWin32Alloc.h #ifndef MAX_VIRTUAL_MEMORY #define MAX_VIRTUAL_MEMORY 512*1024*1024 #endif first i raised it to 768 Mbytes.. same behavior. then i raised it to 1Gb and again same behavior.. So, either this constant is overridden somewhere or it actually doesn't affecting the low-space detection mechanism as i would expect. Any suggestions? I will continue looking , what happens on VM side, but in addition to that, i think we should do something on image side as well: - a low space watcher should not pop up before passing image startup, because if preempted process is UI process (and in 99.99% cases it is), then it means that low space watcher blocks UI process and as a consequence, your image stops handling events. Also, i thinking about different approach for signaling a low space condition. Instead of signaling a low space semaphore, what VM could do is to fail an allocation primitive and set the error code to "low memory warning" then a primitive failure code could actually throw an exception, which then could be handled as usual... so you could write a code, like: [ self allocateSomethingReallyHuge ] on: LowMemoryWarning do: [:err | self shouldWeReallyCare ifFalse: [ self tellVMThatItsOk. err resume ] ifTrue: [ err pass ] ] Because by preempting a currently active process, which "possibly" causing a memory problems is not a solution, as you can see, if it happens during startup phase, then you it just stucks and image hangs. But if we could use exceptions, we could just ignore this warning (or do something else) during image startup, instead of blocking UI process , showing a useless popup message and letting image hang like that. -- Best regards, Igor Stasenko AKA sig.

1 0

VM Maker: VMMaker-dtl.233.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 16 May '11

16 May '11

1 0

BalloonEnginePlugin>>primitiveAddPolygon
by Eliot Miranda 13 May '11

13 May '11

...contains a ^interpreterProxy pop: 6 which should read ^interpreterProxy pop: 5. :)

2 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2011