Re: [Pharo-dev] [rmod] About the infinite debugger

Hi, Normally the pull request should break the exception tests, especially the ones with nested handler, since they are the reason 199 marked signalling contexts were introduced. Looking quickly this test in latest Pharo 7 for example: ExceptionTests>>testHandlerContext fails with the pull

Re: [Pharo-dev] Why do we have SmallDictionary?

ses before starting this thread). Such a suite might > also prevent these sorts of questions on the mailing list in the future, or > at least might make it easier to answer them. > > > > > On 8 June 2018, at 13:01, Andres Valloud wrote: > > In addition, open addressing with line

Re: [Pharo-dev] Sista & Pharo 7

Latest release is on Pharo 6 ( https://clementbera.wordpress.com/2017/07/19/sista-open-alpha-release/) That's the release where the published benchmarks happened and where multiple developers got involved. No plan to release on Pharo 7 alpha. Ask again once Pharo 7 is released. Repository is in

Re: [Pharo-dev] Athens based game worked on windows and pharo 60 :)

On Tue, May 1, 2018 at 1:21 PM, H. Hirzel wrote: > Hello Stef > > Is this Athens based game available somewhere? > > It's not the same game, but I wrote 2 real-time Athens based game and they're available on my github: - Spider Invasion: Minimal game if you're

Re: [Pharo-dev] Hierarchy (roots) of package

I would do that: Implementation: rootsInsidePackage := [ :packageName | | myPackage | myPackage := RPackageOrganizer default packageNamed: packageName. myPackage definedClasses select: [ :each | each superclass package ~~ myPackage ] ]. Example use-case: rootsInsidePackage value:

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

On Tue, Apr 17, 2018 at 2:08 PM, Thierry Goubier <thierry.goub...@gmail.com> wrote: > 2018-04-17 14:03 GMT+02:00 Clément Bera <bera.clem...@gmail.com>: > > Hi Pavel, > > > > I'm looking at PosixSharedMemory again since I have to write a Master > > student pr

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

Hi Pavel, I'm looking at PosixSharedMemory again since I have to write a Master student proposal and I think this could be a good topic. I'm not really expert on SharedMemory, so I'm going to share what I have in mind, we can discuss about it, you could also co-supervise the student indirectly

[Pharo-dev] Using Metacello+git+tonel ?

Hi, I am trying to write a Metacello configuration loading code from git in the tonel format. I checked all the configurations present in the default Pharo image looking for examples, but it seems most of them load code with Monticello. I found ConfigurationOfPharoMetacello which loads code

Re: [Pharo-dev] renaming Matrix to 2dArray

Hi, long time ago I renamed 2DArray as Matrix. Now our Matrix class does > not support any of the Matrix operations Some Matrix operations are implemented: - I see in Matrix class #+*, #preMultiplyByArray:, #preMultiplyByMatrix: which are Matrix specific arithmetic (Multiplication of Matrix by

Re: [Pharo-dev] Discord server vanished!

Yeah it's been down for already 11 hours or something like that. On Sat, Mar 10, 2018 at 3:12 AM, Sean P. DeNigris wrote: > Vincent.Blondeau wrote > > https://discordapp.com/invite/Sj2rhxn > > I confirm this doesn't work. Clicking Accept leads to an error. > > > > - >

Re: [Pharo-dev] control flow graph

ri, Feb 23, 2018 at 11:47 AM, Clément Bera <bera.clem...@gmail.com> > wrote: > > I used that in the past on intermediate representations, I feel it is > very > > useful to directly edit the code of methods with large control flows > since > > when you have many cl

Re: [Pharo-dev] control flow graph

I used that in the past on intermediate representations, I feel it is very useful to directly edit the code of methods with large control flows since when you have many closing brackets ] ] ] ] you never know where to write your code. Now it's specific to some use-cases such as algorithms where

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > > On 22 Feb 2018, at 10:41, Clément Bera <bera.clem...@gmail.com> wrote: > > > > > > > > On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse < > stepharo.s...@gm

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

? > Stef > > On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera <bera.clem...@gmail.com> > wrote: > > Hi, > > > > It seems the two methods have exactly the same behavior indeed. > > valueWithPossibleArgs: anArray > > valueWithEnoughArguments: anArray > &

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Hi, It seems the two methods have exactly the same behavior indeed. valueWithPossibleArgs: anArray valueWithEnoughArguments: anArray One was edited recently but I think it's only to change the comment, they're both very old. My guess is that there are two for compatibility purpose (One is the

Re: [Pharo-dev] VMs build process restored

Thank you very much Esteban, Thanks Fabio. On Tue, Feb 6, 2018 at 5:58 PM, Esteban Lorenzano wrote: > (it was broken since december) > > Which means latest vm versions are latest builds from OSVM: > > 64bit > > •

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

wrote: > Hi Clément, > > On 19 January 2018 at 17:21, Alistair Grant <akgrant0...@gmail.com> wrote: > > Hi Clément, > > > > On 19 January 2018 at 17:04, Clément Bera <bera.clem...@gmail.com> > wrote: > >> Does not seem to be related to prim 105. >

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

can find here the 32 bits versions : http://files.pharo.org/vm/pharoS-spur32/ ? The StackVM/PharoS VM is the VM without the JIT, it may be since the bug is unreliable that it happens only in jitted code, so trying that out may be worth it. On Thu, Jan 18, 2018 at 7:12 PM, Clément Bera <bera.c

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

I would suspect a bug in primitive 105 on byte objects (it was changed recently in the VM), called by copyFrom: 1 to: readCount. The bug would likely by due to specific alignment in readCount or something like that. (Assuming you're in 32 bits since the 4 bytes are corrupted). When I get better I

Re: [Pharo-dev] (Morph>>#asDraggableMorph) isPrimitive

On Sat, Jan 6, 2018 at 8:07 PM, Eliot Miranda wrote: > Hi Denis, Hi Norbert, > > On Sat, Jan 6, 2018 at 6:30 AM, Denis Kudriashov > wrote: > >> Hi. >> >> I guess "quick" methods are compiled as special primitives. For example >> accessors are

Re: [Pharo-dev] Calling primitiveFailed

Hi Norbert, Not really. First we distinguish two cases: - essential primitives : provides features that cannot be implemented in Smalltalk (SmallInteger>>#+ for instance, requires to use the cpu addition) - optimisation primitives : optional, they just improve performance Optimisation

Re: [Pharo-dev] Simple game framework

ns/Sparta with another 2D engine (such as engines used by web browsers). > > Hilaire > > > Le 25/12/2017 à 19:32, Clément Bera a écrit : > >> >> https://github.com/clementbera/wizard-battle-arena >> >> https://github.com/clementbera/SpiderInvasion >>

Re: [Pharo-dev] Simple game framework

See those ReadMe: https://github.com/clementbera/wizard-battle-arena https://github.com/clementbera/SpiderInvasion Audio has always been a problem to me. I successfully run audio files with the open AL binding, but I failed to do so cross-platform. Already key-bindings coherent cross platform

Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap)

hum... The mail is very long so I did not read all of it. Here are some ideas/things to say on the tip of my head: - Changing an object to a forwarding object is non atomic (we need to maintain at least stack invariant) - To decrease the pauses in full GC I have 2 plans: -- incremental marking

Re: [Pharo-dev] Alternative bytecode sets demo request

To use the alternate bytecode set in Pharo 7 use: CompilationContext bytecodeBackend: EncoderForSistaV1. OpalCompiler recompileAll. based on: https://clementbera.wordpress.com/2017/07/19/sista-open-alpha-release/ Currently in Pharo SqueakV3PlusClosure and SistaV1 are installed in

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

Hi, So you're advocating for solution 1: > > 1) We change the instVarAt: / instVarAt:put: primitives comments in Pharo > to match > the slotAt: / slotAt:put: primitives behavior I marked in bold the changes in the Pharo comment (so the comment now reflects the actual behavior): instVarAt:

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

us.den...@inria.fr> wrote: > > > On 24 Nov 2017, at 00:21, Clément Bera <bera.clem...@gmail.com> wrote: > > > > On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse <stepharo.self@gmail. > com> wrote: > >> Did you talk with marcus? >> > &g

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > Did you talk with marcus? > I don't understand the connection between slots and this problem with primitives. > > > On Wed, Nov 22, 2017 at 10:12 PM, Clément Bera <bera.cl

Re: [Pharo-dev] OpalCompiler evaluate speed

Hi Nicolas. Just some comments: Another thing you can try is to remove the allocation of Opal's IR. It seems people use the IR only through the IRBuilder, so the API can be kept but it can generate directly bytecode instead of IR then bytecode. Removing those allocations would speed things up.

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

; On Wed, Nov 22, 2017 at 2:35 PM, Clément Bera <bera.clem...@gmail.com> > wrote: > > Hi All, > > > > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that > the > > instVarAt: / instVarAt:put: primitive is not doing what it says it does. > > When

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

On Wed, Nov 22, 2017 at 3:34 PM, Denis Kudriashov <dionisi...@gmail.com> wrote: > Hi. > > Just to notice: it is here long time (I checked Pharo 1 and current > Squeak). > > Probably some Spur changes to integrate in the image then. > > 2017-11-22 14:35 GMT

[Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

Hi All, It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the instVarAt: / instVarAt:put: primitive is not doing what it says it does. When I look at Object>>#instVarAt: I see: "[...]Answer a fixed variable in an object. The numbering of the variables corresponds to the

Re: [Pharo-dev] UFFI/Sista/Scorch

Hi Ben, This is the work that Ronie did. You have lower level bytecodes in the SistaV1 bytecode set which can be used for parameters marshalling. Ronie has a prototype where the marshalling of FFI calls is generated image-side once and reused for all calls. For now, if Scorch does not recognise

Re: [Pharo-dev] Preferences location on linux and windows?

On Sun, Oct 29, 2017 at 9:27 PM, Stephane Ducasse wrote: > tx! > I would have never guessed it. > That's normal, nobody would have guessed it because it's not a guess. Instead of guessing, one can just use any of the Pharo search engine which allow to find anything in

Re: [Pharo-dev] feenk log

Hi, Good work, In PolyMaths/SciSmalltalk vectors and matrix are already implemented efficiently. I would recommend to share the same implementation. In the next few years, I think we will improve the performance of those vectors/matrix library using the processor vector instructions, and it

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

Hi again, I checked with Stef this morning. Starting the image on a VM without Freetype solves the problem. Just open the VM, remove or rename the Freetype dynamic libraries (FT2, Freetype, 3 libs in total), then start your image. That's unfortunate the hexadecimal editor solution is so much

Re: [Pharo-dev] Primitive Failed error trying openInExternalWindow

Hi Eduardo, Your FFIStructures are not initialised (I thought this was solved in latest Pharo 7 ? Maybe not integrated yet). Run: FFIExternalStructure allSubclassesDo: #rebuildFieldAccessors. Then your code should work. I wrote a simple game using Pharo/SDL2/Cairo and it works very well (50fps

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

On Sat, Oct 21, 2017 at 6:23 PM, Peter Uhnák wrote: > #(FT2Handle FreeTypeCache FreeTypeSettings) do: [ :each | SessionManager >> default unregisterClassNamed: each ] >> > > How am I supposed to launch the script if it crashes on startup? I've > tried running from terminal

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

Hi, As you can see in the crash dump, this is always due to FreeType. If it's only at start-up it means it's in the FreeType start-up code. You can try to change some free type settings (like not using those fonts at all) or to use more hard-core scripts such as: #(FT2Handle FreeTypeCache

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

On Wed, Oct 18, 2017 at 3:27 PM, Jan Vrany wrote: > Hi, > > > I was thinking of changing that, adding a primitive which answers a > > CogMethod as a bytearray, but you still need to use external libs > > such as gdb/lldb to disassemble your binary > > I use udis86 [1] for

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

On Wed, Oct 18, 2017 at 1:42 PM, Mariano Martinez Peck < marianop...@gmail.com> wrote: > > > On Wed, Oct 18, 2017 at 3:36 AM, Tudor Girba wrote: > >> Hi, >> >> This is already available since some time in the GTInspector. You can >> just inspect a compiled method. You will

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

@gmail.com> > wrote: > > Hi Clément, > > > > I just checked on my machine and it is also not working. It seems to be > a VM > > bug. It will take me some time to debug it. I have some suspicious on > > ioProcessEvents . > > > > Best regards, >

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

You can do that with the VMMaker package loaded. There is not all the UI, but you can print the assembly code in the Transcript. On Tue, Oct 17, 2017 at 10:03 PM, Esteban A. Maringolo wrote: > I'm sure we could do this with ease, because we already can see the >

Re: [Pharo-dev] [Pharo 7.0-dev] Build #176: 20505-The-special-objects-array-needs-to-be-recreated-during-bootstrap

Hi Guille, For "First": I looked into this problem with Pavel this morning. The special object array being incorrectly created leads to problems when a large object (bigger that growthHeadroom) is created, as it does not go through the handleFailingBasicNew methods. Typically, Pavel could not

Re: [Pharo-dev] Sista alternate bytecodes + Java Bytecode ?

Hi, That question should be asked on vm-dev. Just a detail, multibytecode set support is prior to the Sista implementation, it was used for example in the context of Newspeak (Squeak and Newspeak bytecodes supported together). Sista uses that feature, which makes it look like new in the Pharo

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

on how to deploy Pharo client app with SDL2 and Cairo but I have only a version working in Pharo 4 on Mac and Linux, while in theory I could have it working in Windows/Mac/Linux in the latest Pharo. > Hilaire > > > > Le 28/09/2017 à 15:02, Clément Bera a écrit : > >> Btw for som

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

gt;>> >>> Btw for some reason in the one-click version of Pharo 32 bits on Mac >>>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to >>>> conflicts (the VM use randomly one lib or the other). I randomly chose one >>>> that I use and

[Pharo-dev] OSWindow in Pharo 6.1 stable

Hi Ronie, Hi all, I am trying to use OSWindow/SDL2 in Pharo 6,1 stable, I successfully opened the window and I can draw on it with Athens (with minor changes compared to Pharo 4). However, the user events (keyboard, mouse, etc.) are not working. It seems some constants are not initialized but I

Re: [Pharo-dev] Pharo7 and full block closures

another parallel stage in the PR validation. So once it is stable we can detect asap changes that break it. Cheers, On 22 Sep 2017 18:45, "Clément Bera" <bera.clem...@gmail.com> wrote: Well we need to use them but the integration process is difficult to deal with: we need to chang

Re: [Pharo-dev] Pharo7 and full block closures

, "Stephane Ducasse" <stepharo.s...@gmail.com> wrote: > Hi clement > > let us know how we can help because he all want the new closures. > > Stef > > On Fri, Sep 22, 2017 at 11:11 AM, Clément Bera <bera.clem...@gmail.com> > wrote: > > I totally agree

Re: [Pharo-dev] Pharo7 and full block closures

broken... Regards On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther <hol...@freyther.de> wrote: > > > On 22. Sep 2017, at 13:33, Clément Bera <bera.clem...@gmail.com> wrote: > > > Hi Clement, > > > > Sista will work for the release of Pharo 7 as it d

Re: [Pharo-dev] Pharo7 and full block closures

Hi Holger, Nobody can guarantee any framework to be stable on Pharo alpha (Currently Pharo 7) since deep changes can happen every day during alpha. So the answer is yes, having any framework *not* working on the alpha version is to be expected. The instructions to use the Sista runtime are

Re: [Pharo-dev] Discussing the roadmap

The incremental GC is already mentioned in "Better support for large heaps (GC tuning API, incremental GC)". Now we have a second paragraph about the incremental GC, that's redundant and the form of the paragraph is not consistent with the rest of the roadmap where each feature has 1 or 2 lines of

Re: [Pharo-dev] Pharo 7 provisional HOWTO

Hi all, Just to be clear, in Pharo 7, if I want to get some code integrated: - I *have to* use the pull request process described by Pavel OR - I *can* use the pull request process, but I can also use the old slice monticello process ? What is the answer to the first question now, and what will

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

o work at least in Squeak and Pharo, I don't want to add extra code so it uses different frameworks in different platforms and then maintain this extra code. > > > On Tue, Jun 20, 2017 at 3:10 PM, Clément Bera <bera.clem...@gmail.com> > wrote: > > Hi Thierry, hi all, > &g

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

Ok. Maybe when things are fixed we should update the Pharo 6 release version (the one-click) to have a version with OSProcess working. Cyril the production Pharo VM are now generated from opensmalltalk-vm. There is no separate Pharo build. Just saying to avoid fireworks. On Tue, Jun 20, 2017 at

[Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

Hi Thierry, hi all, The Pharo catalog version of OSProcess is not working in the Pharo 6 release and I need to load OSProcess in one of my projects. I cannot load OSSubProcess instead, so no need to answer this mail talking about it. In-between version 2231 and 2241 of VMMaker, the vm parameter

Re: [Pharo-dev] immediateByteSubclass: ?

This one looks strange and seems indeed to be dead code. Maybe it was an attempt to make a specific class definition keyword for CompiledMethod / CompiledCode / CompiledBlock. Right now there is a specific case in the code somewhere to use the specific compiledCode layout for those 3 classes

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo <emaring...@gmail.com> wrote: > 2017-05-10 13:38 GMT-03:00 Clément Bera <bera.clem...@gmail.com>: > > On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo < > emaring...@gmail.com> wrote: > > >&g

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

> Then let Esteban accept the request or not before the release of Pharo... > > (if the build are green, there's no reason to not accept it). > > > > 2017-05-10 15:39 GMT+02:00 Max Leske <maxle...@gmail.com>: > >> > >> OK, I see. > >> > >> >

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

Hi Max, She has already done that. The point is to add the plugins in the default Pharo VM, so everyone can use the VM profiler. We would like to have the VM profiler loadable through the Pharo catalog, but many people won't be able to use it if the default Pharo VM does not support it... The

Re: [Pharo-dev] resizing the windows sometimes blocks the image

Hi Try resizing the window and clicking inside it a couple times. It usually refreshes the surface correctly and avoids the need to force quit. I think it happens to other people too, it seems it's exclusive to Mac OS X. Best, On Wed, May 3, 2017 at 10:23 AM, Andrei Chis

Re: [Pharo-dev] changing default theme to DarkTheme

Isn't a couple days before release a bit late to change the default theme ? Aren't we in feature freeze mode ? If for marketing it makes sense to switch to the dark theme, then let's switch to dark theme. But why not switching for Pharo 7 instead ? Instability is bad for marketing anyway, isn't

[Pharo-dev] String hash function

Hi all, I am trying to investigate performance overhead in benchmarks to improve the VM performance. In a benchmark strings are used as dictionary keys, which seems to be an OK pattern to me that may be actually used in real code from time to time. Something stroke me: *the hash function of a

Re: [Pharo-dev] Growing large images: the case of Moose models

e next few months to make VM tuning easier to deal with. I will update the scripts in the blog post accordingly if I do so. Best, On Sat, Mar 4, 2017 at 12:49 AM, stepharong <stephar...@free.fr> wrote: > tx clement > > this is indeed really important > > On Fri, 03 Mar 20

Re: [Pharo-dev] Really amazing bug (or feature) with compiling some ifTrue expressions

The problem is that in this case: 10 ifTrue: [ #falseResult. ]. #unexpectedResult. #falseResult => is used for effect. Opal removes it. 10 ifTrue: [ #falseResult. ] => is used for effect. Opal removes it. The bytecode ends up being: *29 <20> pushConstant: 10* *30 <87> pop* *31 <78>

Re: [Pharo-dev] Growing large images: the case of Moose models

On Fri, Mar 3, 2017 at 2:10 PM, Cyril Ferlicot D. wrote: > On 03/03/2017 14:06, Guillaume Larcheveque wrote: > > > > For your case: > > - Do you care that your application use some more Mb of RAM ? > > > > No, we don't care about that > > I agree > > > > > -

Re: [Pharo-dev] Growing large images: the case of Moose models

On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D. <cyril.ferli...@gmail.com > wrote: > On 03/03/2017 11:56, Clément Bera wrote: > > Hello everyone, > > > > This morning I investigated with Vincent Blondeau a problem reported by > > the Moose community a while a

[Pharo-dev] Growing large images: the case of Moose models

Hello everyone, This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size. To

Re: [Pharo-dev] strange idea about slots

On Wed, Mar 1, 2017 at 3:56 PM, Ben Coman wrote: > > I'm not sure I'm thinking straight, but I wonder... > Can you put Slots inside an Association? > > For example, could have two slots x and y, > and then be able to do the following... > > (x -> y) substitute: (1 ->

Re: [Pharo-dev] Is Moz2D ready for Android?

Hey Denis. Basically, does firefox work in Android ? Yes. Therefore, Moz2D can be built for Android. Moz2D uses internally one of these 2 libraries: Cairo or Skia. Cairo is supposed to be working on Android. Skia works for sure on Android as it has been the default graphic framework there since

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

On Fri, Feb 17, 2017 at 1:48 PM, Cyril Ferlicot D. <cyril.ferli...@gmail.com > wrote: > Le 17/02/2017 à 13:31, Clément Bera a écrit : > > > > > > It may solve part of the problem. > > > > Another problem is that tenure heuristics needs to be changed when &g

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

On Fri, Feb 17, 2017 at 12:05 PM, Cyril Ferlicot D. < cyril.ferli...@gmail.com> wrote: > Le 17/02/2017 à 07:17, Clément Bera a écrit : > > The full GC is indeed much faster as the previous compaction algorithm > > was very slow. But unless you were executing memory inten

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

xecuting memory intensive code in very large heaps, you won't see much difference as full GC are uncommon. We still need to make the GC incremental to avoid pauses ... > > On 16 Feb 2017, at 17:16, Clément Bera <bera.clem...@gmail.com> wrote: > > > > Hi all, > > > >

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

Hi all, A temporary solution had been integrated in the VM a year ago, but only part of the problem was solved. This issue has been entirely solved in the VM through the implementation of a new compactor for the full GC. The new compactor (called the planning compactor) has been marked as the

Re: [Pharo-dev] Segmentation fault while installing Scale

Hi Andrey, Thanks for providing both a way to reproduce and the log so we can have you machine details. I see that the VM was compiled from build #589 on jenkins with VMMaker.oscog-eem.1855 and you're on Linux using x86 back-end. Scale works only on Linux and when I try the wget command from Mac

Re: [Pharo-dev] Immutability support

add VM support for this case. On Thu, Jan 26, 2017 at 11:36 AM, Denis Kudriashov <dionisi...@gmail.com> wrote: > > 2017-01-26 10:59 GMT+01:00 Clément Bera <bera.clem...@gmail.com>: > >> Let's rewrite the method this way: >> >> attemptToAssign: value withIndex: in

Re: [Pharo-dev] Immutability support

suspendedContext: process suspendedContext sender ] fork. Processor yield. I don't know how to explain it better. I understand that because it was bugged it was very hard to understand. I will put a slice on the bug tracker. On Thu, Jan 26, 2017 at 10:35 AM, Clément Bera <bera.clem...@gma

Re: [Pharo-dev] Immutability support

Kudriashov <dionisi...@gmail.com> wrote: > > 2017-01-26 8:11 GMT+01:00 Clément Bera <bera.clem...@gmail.com>: > >> The "CAN'T REACH" comment is there because execution never reach that >> part of the code. If you write code there, it will never be

Re: [Pharo-dev] Immutability support

On Thu, Jan 26, 2017 at 9:54 AM, Norbert Hartl <norb...@hartl.name> wrote: > > Am 26.01.2017 um 08:11 schrieb Clément Bera <bera.clem...@gmail.com>: > > The "CAN'T REACH" comment is there because execution never reach that part > of the code. If you write

Re: [Pharo-dev] Immutability support

The "CAN'T REACH" comment is there because execution never reach that part of the code. If you write code there, it will never be executed. The process code performs a return without pushing any value on stack. Signalling an error is safe if the error is never resumed. But you'll need the

Re: [Pharo-dev] Immutability support

may look like it works when returning a value but you will have uncommon crashes. > 2017-01-25 16:21 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: > >> >> 2017-01-25 15:52 GMT+01:00 Clément Bera <bera.clem...@gmail.com>: >> >>> Overall, you need t

Re: [Pharo-dev] Immutability support

Norbert, On Wed, Jan 25, 2017 at 3:36 PM, Norbert Hartl <norb...@hartl.name> wrote: > Clément, > > Am 25.01.2017 um 13:54 schrieb Clément Bera <bera.clem...@gmail.com>: > > > > On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norb...@hartl.name> wr

Re: [Pharo-dev] Immutability support

> 2017-01-25 13:59 GMT+01:00 Clément Bera <bera.clem...@gmail.com>: > >> It also raise another question: does these primitives support mirror >>> approach? (when it can be called with receiver as first argument?) >>> >> >> Yes I made sure the mirror

Re: [Pharo-dev] Immutability support

te: Sun Jan 15 15:42:39 2017 +0100 $ Plugins: > 201701151442 https://github.com/pharo-project/pharo-vm.git $ > CoInterpreter * VMMaker.oscog-eem.2090 uuid: > 63a161b9-17e1-4911-a89a-1687d9ba9a1a > Jan 15 2017 > StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: > 63a161b9-17e1-4

Re: [Pharo-dev] Immutability support

On Wed, Jan 25, 2017 at 12:59 PM, Esteban Lorenzano wrote: > but this is not real immutability, is like a write barrier, that’s why > those method names were not chosen. > As Esteban mentioned, read-only objects are not immutable objects, that's why we didn't use these

Re: [Pharo-dev] Immutability support

Hi again. On Wed, Jan 25, 2017 at 12:04 PM, Denis Kudriashov wrote: > > 2017-01-25 12:03 GMT+01:00 Denis Kudriashov : > >> I think problem that these names could be already in use by frameworks. I >> am sure #isReadOnly, #beReadOnly is used in many

Re: [Pharo-dev] Immutability support

On Wed, Jan 25, 2017 at 11:55 AM, Denis Kudriashov wrote: > > 2017-01-25 11:47 GMT+01:00 Norbert Hartl : > >> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for >> testing methods. isXXX with an argument feels even more strange. I

Re: [Pharo-dev] Immutability support

On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl wrote: > Does anyone know the state of immutability support in vm and image? The > latest vm downloadable is compiled with > > IMMUTABILITY=1 > > (Esteban said that). When I open a pharo6 image with this VM and do: > > ASUser

Re: [Pharo-dev] Collections and Kernel

set of classes and enforce my package to depend only on those classes as the current packages are too wide and they won't be split in a way I need in the near future. Cheers > But of course we should discuss the best approach. > > Cheers, > -- Pavel > > > > 2017-0

[Pharo-dev] Collections and Kernel

Hi everyone, As I am working on an optimising JIT compiler for the Cog VM written in Smalltalk and partly running in the Smalltalk runtime, I am very careful about dependencies. I would like to limit the dependencies of the optimiser to the Kernel. The main problem I have is that there are no

Re: [Pharo-dev] About more precise default exception?

I agree this exception should be more specific. By the way one needs to update all the primitive mutating objects, such as at:put:, so that when it fails because it attempts to mutate a read-only object a proper error is raised instead of SubscriptOutOfBounds with an in-bound index. Maybe an

Re: [Pharo-dev] PharoSpur32Vm

Hi, I believe they're built from* https://github.com/OpenSmalltalk/vm * using travis and appveyor. On the gitbhub readme there are relevant links. All built artifacts are also kept on bintray for history. On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess

Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?

Hi Igor. People at Mines de douai were working on Pharo with ROS. Contact Luc Fabresse or Noury Bouraqadi, people like Santiago, Guillermo polito or Nick Papoulias may also be aware of the work. I don't know what was done exactly. Have fun. On Thu, Dec 22, 2016 at 9:38 PM, Igor Stasenko

Re: [Pharo-dev] genJumpLong: distance index 1043 is out of range -1024 to 1023

Hi, This will be fixed by using the alternative bytecode set, likely in the next few weeks in Pharo 6 alpha/beta. Basically control flow messages (ifTrue:, to:do:, etc.) cannot have too many statements in their blocks (ifTrue: argument, to:do: second arguments, etc) or the compiler can't compile

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

Both are used for each compilation. They're instance variables of each other. | *Who decides which to use* In each AST node translation, you know for each value which one to use. For example, when translating a return, the value to return needs to be pushed on stack, so the valueTranslator is

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

On Mon, Dec 5, 2016 at 8:51 AM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > Translate AST to byte codes? > One for the case when we don't care of the result (we will pop it off the > stack), we just want the effect. > The other case when we want to keep the resulting value on

Re: [Pharo-dev] About ~= and ~~

Hi Do you mean you want to add this pragma "" in Object >> #~~ ? Or do you mean replacing #blockCopy: by #~~ in the special selectors to get it inlined by default like #== ? On Wed, Nov 23, 2016 at 2:39 PM, Aliaksei Syrel wrote: > Hi > > It is been a while... > So, do

Re: [Pharo-dev] Windows 64 bits VM?

There is a Stack VM (VM without JIT) for Windows 64 working. It works since yesterday so it's not integrated in automated builds and you need to compile it yourself. On Wed, Nov 16, 2016 at 12:01 AM, Gabriel Cotelli wrote: > Hi, > Is there a Windows 64 bits VM ready to

Re: [Pharo-dev] Performance difference between Pharo 32bits and 64bits

Hi Thierry, On the speed center you can compare 32 bits and 64 bits linux VMs: http://squeak.org/codespeed/ Normally Pharo 64 should be overall slightly slower than Pharo 32 because 70% of the memory is used for pointers, implying twice more data to process by the processor for pointer

  1   2   3   4   5   >