libcairo2:amd64 1.15.2-0intel1 is clearly not from the official repository.
See on my ubuntu17.04: hilaire@PCHome:~$ dpkg -l | grep libcairo2 ii libcairo2:amd64 1.14.8-1 amd64 Cairo 2D vector graphics library ii libcairo2:i386 1.14.8-1 i386 Cairo 2D vector graphics library ii libcairo2-dev 1.14.8-1 amd64 Development files for the Cairo 2D graphics library If you can wipe it out, you may sort out. Hilaire Le 29/09/2017 à 12:48, Igor Stasenko a écrit : > package libcairo2:amd64 1.15.2-0intel1 cannot be configured because > libcairo2:i386 is at a different version (1.14.8-1) > Processing triggers for libc-bin (2.24-9ubuntu2.2) ... -- Dr. Geo http://drgeo.eu |
On 29 September 2017 at 22:05, Hilaire <[hidden email]> wrote: libcairo2:amd64 1.15.2-0intel1 is clearly not from the official repository. most probably it is due to my attempts to make my hybrid graphics setup work.. i bought this laptop year ago and then figured out, that there are issues with X11 and kernel drivers that prevents using both video cards on board.. and installing latest & finest didn't changed much. Best regards,
Igor Stasenko. |
Hi Igor et al., thanks for taking a look at this. I appreciate it a lot. I've been swamped with work et al. but I'm back. If I understand it correctly, Igor is still fighting with drivers to make it work on his system. Let me know when you want me to try something. Cheers, Jeff On Fri, Sep 29, 2017 at 3:22 PM Igor Stasenko <[hidden email]> wrote:
|
On 30 September 2017 at 17:51, J.F. Rick <[hidden email]> wrote: --
Sure. But i didn't done much, so there's nothing to appriciate yet :) But i want to help, if it won't require reinstalling OS, because i need my machine in working condition almost 24/7.. so i cannot take too much risk with it :(
Best regards,
Igor Stasenko. |
All these difficulties are good argument to get the appropriate
libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM Hilaire Le 30/09/2017 à 21:58, Igor Stasenko a écrit : > Sure. But i didn't done much, so there's nothing to appriciate yet :) > But i want to help, if it won't require reinstalling OS, because i > need my machine in working condition almost 24/7.. so i cannot take > too much risk with it :( -- Dr. Geo http://drgeo.eu |
Le 01/10/2017 à 09:26, Hilaire a écrit :
> All these difficulties are good argument to get the appropriate > libcairo/libpng shipped with the Linux VM, as done with Windows and > MacOSX VM This cause surprising problems in Pharo integration with the platform: for example, if you use a system library or an external command with Pharo as it is set now, that command will use Pharo libpng instead of the one it was compiled with (because pharo use of LD_LIBRARY_PATH will be inherited). Took me a while for example to understand that, when using the snap version of Pharo, Python3 scripts called from Pharo would be unable to import libraries such as numpy. But that works fine with the zeroinstall version of Pharo. Thierry > Hilaire > > > Le 30/09/2017 à 21:58, Igor Stasenko a écrit : >> Sure. But i didn't done much, so there's nothing to appriciate yet :) >> But i want to help, if it won't require reinstalling OS, because i >> need my machine in working condition almost 24/7.. so i cannot take >> too much risk with it :( > |
In reply to this post by HilaireFernandes
On 1 October 2017 at 10:26, Hilaire <[hidden email]> wrote: All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM Nah, in my case, there's nothing that can be lableled as "Pharo fault". It is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library. Hilaire Best regards,
Igor Stasenko. |
I had situation where the system libcairo:i386 does not work with
Dr.Geo[1], Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo fault, but I am definitely stuck. It is problematic, it is a system (LinuxMint based) used in Geneva primary schools and Dr. Geo was expected to be used there :( Hilaire [1] http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html Le 01/10/2017 à 19:50, Igor Stasenko a écrit : > > All these difficulties are good argument to get the appropriate > libcairo/libpng shipped with the Linux VM, as done with Windows > and MacOSX VM > > Nah, in my case, there's nothing that can be lableled as "Pharo > fault". It is definitely a linux/ubuntu ecosystem fault. - by not > providing parallel updates for 32 & 64 bit variant of same library. -- Dr. Geo http://drgeo.eu |
How could we help?
On Sun, Oct 1, 2017 at 9:14 PM, Hilaire <[hidden email]> wrote: > I had situation where the system libcairo:i386 does not work with Dr.Geo[1], > Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo > fault, but I am definitely stuck. > > It is problematic, it is a system (LinuxMint based) used in Geneva primary > schools and Dr. Geo was expected to be used there :( > > Hilaire > > [1] http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html > > > Le 01/10/2017 à 19:50, Igor Stasenko a écrit : >> >> >> All these difficulties are good argument to get the appropriate >> libcairo/libpng shipped with the Linux VM, as done with Windows >> and MacOSX VM >> >> Nah, in my case, there's nothing that can be lableled as "Pharo fault". It >> is definitely a linux/ubuntu ecosystem fault. - by not providing parallel >> updates for 32 & 64 bit variant of same library. > > > -- > Dr. Geo > http://drgeo.eu > > > |
We tested it on P6.1 64bits, and this Cairo crash seems to be gone. It
may need more testing though. Is it thanks to P6.1 or the 64bits image/VM? It looks strange because it looked like a lib Cairo crash, but in the other hand the faulty C function did not appear to be called from Pharo image. What need to be done porting to P6.1, is mainly image shrinking, fix of several bugs from P6.1 impacting drgeo, working setup for linux/windows/mac. Still some job. Hilaire Le 02/10/2017 à 15:19, Stephane Ducasse a écrit : > How could we help? > > > On Sun, Oct 1, 2017 at 9:14 PM, Hilaire<[hidden email]> wrote: >> I had situation where the system libcairo:i386 does not work with Dr.Geo[1], >> Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo >> fault, but I am definitely stuck. >> >> It is problematic, it is a system (LinuxMint based) used in Geneva primary >> schools and Dr. Geo was expected to be used there:( >> >> Hilaire >> >> [1]http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html >> >> >> Le 01/10/2017 à 19:50, Igor Stasenko a écrit : >>> All these difficulties are good argument to get the appropriate >>> libcairo/libpng shipped with the Linux VM, as done with Windows >>> and MacOSX VM >>> >>> Nah, in my case, there's nothing that can be lableled as "Pharo fault". It >>> is definitely a linux/ubuntu ecosystem fault. - by not providing parallel >>> updates for 32 & 64 bit variant of same library. >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> -- Dr. Geo http://drgeo.eu |
Just a quick follow up: We've found that if we are in fullscreen Pharo mode on Linux and hit the ALT button twice, the Athens-based rendering speeds up significantly. The first ALT brings the Unity launcher to the foreground. The second ALT bring fullscreen Pharo back to the foreground. I'm not sure why this makes Athens rendering faster but it does. Perhaps that offers a clue as to what is slowing Pharo down in fullscreen on Linux. Cheers, Jeff On Wed, Oct 11, 2017 at 2:56 PM Hilaire <[hidden email]> wrote: We tested it on P6.1 64bits, and this Cairo crash seems to be gone. It |
I don’t have any issues with Linux in full screen mode (Mint 18 KDE and OEL7 UEK KDE) but it sounds like it may be an issue with the Wayland graphics system, and KDE doesn’t use it AFAIK. If so, it may also be driver specific – what graphics card are you using? It is just a guess, but pulling Unity forward switches it out of Wayland graphics mode (used mainly for games etc. that run full screen), if it doesn’t go back into it until a new full screen app starts up it would account for the improvement. Andrew Sent from Mail for Windows 10 From: [hidden email] Just a quick follow up: We've found that if we are in fullscreen Pharo mode on Linux and hit the ALT button twice, the Athens-based rendering speeds up significantly. The first ALT brings the Unity launcher to the foreground. The second ALT bring fullscreen Pharo back to the foreground. I'm not sure why this makes Athens rendering faster but it does. Perhaps that offers a clue as to what is slowing Pharo down in fullscreen on Linux. Cheers, Jeff On Wed, Oct 11, 2017 at 2:56 PM Hilaire <[hidden email]> wrote: We tested it on P6.1 64bits, and this Cairo crash seems to be gone. It > How could we help? > > > On Sun, Oct 1, 2017 at 9:14 PM, Hilaire<[hidden email]> wrote: >> I had situation where the system libcairo:i386 does not work with Dr.Geo[1], >> Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo >> fault, but I am definitely stuck. >> >> It is problematic, it is a system (LinuxMint based) used in Geneva primary >> schools and Dr. Geo was expected to be used there:( >> >> Hilaire >> >> [1]http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html >> >> >> Le 01/10/2017 à 19:50, Igor Stasenko a écrit : >>> All these difficulties are good argument to get the appropriate >>> libcairo/libpng shipped with the Linux VM, as done with Windows >>> and MacOSX VM >>> >>> Nah, in my case, there's nothing that can be lableled as "Pharo fault". It >>> is definitely a linux/ubuntu ecosystem fault. - by not providing parallel >>> updates for 32 & 64 bit variant of same library. >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> -- Dr. Geo http://drgeo.eu |
Interesting. Could be. The specific problem came up on an Intel NUC which uses Intel integrated graphics. Cheers, Jeff On Mon, Nov 6, 2017 at 5:24 PM Andrew Glynn <[hidden email]> wrote:
|
If you stored the settings without full screen mode checked, start up Pharo, then switch in into full screen mode, it should run at full performance if I’m right. I have an intel integrated card + an NVidia, it can work in either mode or in Optimus mode, where it only goes into NVidia if an app requests it or goes full screen. Pharo is very quick in full screen as a result, since I run it in Optimus mode (Linux has issues with the windowing system using the NVidia drivers in normal mode). Since Pharo uses SDL2 for the base graphic subsystem, which is one of the main gaming graphics platforms, it wouldn’t be surprising if Wayland assumed it was a game if it starts full screen, and intel graphics aren’t all that great for gaming (so I’ve heard – I have an Xbox with one game – FIFA, lol). Andrew Glynn From: [hidden email] Interesting. Could be. The specific problem came up on an Intel NUC which uses Intel integrated graphics. Cheers, Jeff On Mon, Nov 6, 2017 at 5:24 PM Andrew Glynn <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |