[Pharo-dev] [Pharo 8.0] Build #1066: Change url in GoverApiTest >>testRepositoryErrors

There is a new Pharo build available! The status of the build #1066 was: SUCCESS. The Pull Request #5363 was integrated: "Change url in GoverApiTest >>testRepositoryErrors" Pull request url: https://github.com/pharo-project/pharo/pull/5363 Issue Url:

Re: [Pharo-dev] [Vm-dev] Debugging GCC code generation

On Thu, 12 Dec 2019 at 04:03, Eliot Miranda wrote: > > Hi Pablo, > > On Wed, Dec 11, 2019 at 11:33 AM teso...@gmail.com > wrote: > >> Hi Nicolas, >> thanks for the comment, you are right the problem is the bad >> original code. But my opinion is that it just is not reporting the >> situation

Re: [Pharo-dev] Debugging GCC code generation

It's the tribute to pay for optimization. With unbounded pointer and pointer aliasing, the C compiler is in the worse world for optimizing. As long as a FORTRAN compiler will beat a C compiler in generated code efficiency, the C guys will have to amend the standard ;) So we have plenty of new

Re: [Pharo-dev] Debugging GCC code generation

On Wed, Dec 11, 2019 at 12:03 PM Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > Yes, > But we have to replace natural crappy code (split a long in 2 ints) that > was once legal, by an even more crappy code (memcpy), so all in all, it's a > crappy art. > :-) Indeed. Personally I

Re: [Pharo-dev] Debugging GCC code generation

Yes, But we have to replace natural crappy code (split a long in 2 ints) that was once legal, by an even more crappy code (memcpy), so all in all, it's a crappy art. Le mer. 11 déc. 2019 à 19:30, teso...@gmail.com a écrit : > Hi Nicolas, > thanks for the comment, you are right the problem is

Re: [Pharo-dev] Debugging GCC code generation

Hi Nicolas, thanks for the comment, you are right the problem is the bad original code. But my opinion is that it just is not reporting the situation correctly, generating a warning or non-optimizing the code looks more like a expected behavior. Because as I have said, using a constant as index

Re: [Pharo-dev] Debugging GCC code generation

Of course, when I say "your" code, it's the code you have shown, and probably "our" (VMMaker) code ;) Le mer. 11 déc. 2019 à 19:05, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> a écrit : > Hi Pablo (again), > no, not a bug. > > The problem is in the source code. The compiler has the

Re: [Pharo-dev] Debugging GCC code generation

Hi Pablo (again), no, not a bug. The problem is in the source code. The compiler has the right to presume that your code is exempt of UB, because you cannot depend on UB (obviously). So it can eliminate all code which corresponds to UB. The compiler has the right to assume that a pointer to an

Re: [Pharo-dev] Debugging GCC code generation

Hi Pablo, pointer aliasing is considered UB indeed and accessing a pointer outside of allocated bounds also is UB the recommended way to perform a between one pointer type and another (reinterpret_cast) is to use memcpy, so it should be: long v; int i[sizeof(long)/sizeof(int)];

Re: [Pharo-dev] Debugging GCC code generation

Hi Aliaksei, to me it looks like a bug of GCC optimization. Basically, it is assuming that the x variable is used but never read or its value is never used. Also it assumes the same of the i variable, as we are only accessing indirectly to the memory where it locates (the code is even

Re: [Pharo-dev] Debugging GCC code generation

Hi Pablo, Wow! Thank you for the detective story :) Do I understand correctly that the original code causes undefined behavior and therefore can be changed (or even removed) by the compiler? (because it returns something that is referencing memory on the stack) Please keep posting similar

[Pharo-dev] Debugging GCC code generation

Hi, this mail is related to Pharo because it is knowledge I found debugging the build of the VM, but the rest is to document it and perhaps someone will found it interesting (also I couldn't find it easily using Google). Sorry for the long mail! The problem == The following code does

[Pharo-dev] [Pharo 8.0] Build #1065: Revert "[Perfs] x10 on method compiling with #deferFlushDuring:"

There is a new Pharo build available! The status of the build #1065 was: SUCCESS. The Pull Request #5359 was integrated: "Revert "[Perfs] x10 on method compiling with #deferFlushDuring:"" Pull request url: https://github.com/pharo-project/pharo/pull/5359 Issue Url:

Re: [Pharo-dev] Willow Bootstrap & JQueryUI loading errors

Sanjay, I've tried it on a Windows machine with a fresh Pharo installation and it works fine. The v12 branch of Willow is pointing to the same commit that v12.1.0 tag so this shouldn't be a problem. Can you describe in more detail the error that you're getting and the steps to reproduce from a

Re: [Pharo-dev] code loading performance

Maybe the best is to revert for now https://github.com/pharo-project/pharo/pull/5359 > On 11 Dec 2019, at 14:39, George Ganea wrote: > > Hi Vincent, > > In the end we tried it after it was merged :) Our CI uses the latest Pharo

Re: [Pharo-dev] code loading performance

Hi Vincent, In the end we tried it after it was merged :) Our CI uses the latest Pharo 8 image. Unfortunately we did not see an improvement, and even worse, it seems to break one of our builds that is downstream from GToolkit. We got all sorts of errors that seemed to be related to incomplete

Re: [Pharo-dev] Willow Bootstrap & JQueryUI loading errors

Hi. I will take a look. Can you file a bug report so I don't forget? v12 must be equivalent to the latest v12.x release. You can load the Deployment group in the baseline if you want faster loading times ( it's all that's needed for runtime), but loading in Windows is slow because Seaside repo is

[Pharo-dev] Willow Bootstrap & JQueryUI loading errors

I get an error when trying to load Willow-bootstrap and willow-JQueryUI using the Metacello script (prior to this I have loaded Willow 12.1.0 first in Pharo 8 / Windows 10) maybe this has something to do with the following line in setUpDependencies: baseline: 'Willow' with: [ spec repository:

[Pharo-dev] [Pharo 8.0] Build #1064: [easyReview] examples in class comment for literalArrayNode

There is a new Pharo build available! The status of the build #1064 was: SUCCESS. The Pull Request #5356 was integrated: "[easyReview] examples in class comment for literalArrayNode" Pull request url: https://github.com/pharo-project/pharo/pull/5356 Issue Url: