May 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] im using pharo in wayland system.

by Thierry Goubier

Le jeu. 24 mai 2018 16:23, peter yoo <onionmixer(a)gmail.com> a Ã©crit : > to Guillermo > where can download pharo 7? cannot find from google. > > to Thierry > hm... same now... install font and fc-cache later is same. > and.... im using nouveau driver. using wayland now :D > Oh, ok, maybe it's a nouveau driver constraint. I installed two fonts. I need to check again. Thierry >

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by peter yoo

to Guillermo > where can download pharo 7? cannot find from google. to Thierry > hm... same now... install font and fc-cache later is same. and.... im using nouveau driver. using wayland now :D

May 24, 2018

Re: [Pharo-users] How to LAN feature

by Hilaire

Yes, it is only to know where is the server, then I will use your Zinc framework for the real exchange stuff. The udp message may just be 'DrGeoShare' Le 24/05/2018 Ã 15:51, Sven Van Caekenberghe a Ã©critÂ : > Yes, each UDP packet always contains both the sender and receiver IP (and port). > But remember UDP is asynchronous and unreliable, as well as limited in payload size. -- Dr. Geo http://drgeo.eu

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by Thierry Goubier

Hi Peter, I've seen the same error on a fresh 18.04 system I have installed last week, and the solution was to add the Open Sans fonts to the user folder (~/.fonts) and rebuild X font cache. By the way, Ubuntu 17.10 was Wayland, Ubuntu 18.04 is not Wayland, as far as I know. And I had Pharo working on both. Regards, Thierry 2018-05-24 14:06 GMT+02:00 peter yoo <onionmixer(a)gmail.com>: > hello! im new install ubuntu 18.04 LTS to my desktop. but pharo cannot run. > > look a attached png then know the problem. cannot using wirh wayland system > now? > > maybe guess.... because freetype.... have a solution then help to me please. > > -- > http://lookandwalk.com http://looknw.com | http://onionmixer.net > peter yoo(Jonghwa Yoo). ROK

May 24, 2018

Re: [Pharo-users] How to LAN feature

by Sven Van Caekenberghe

Yes, each UDP packet always contains both the sender and receiver IP (and port). But remember UDP is asynchronous and unreliable, as well as limited in payload size. > On 24 May 2018, at 15:48, Hilaire <hilaire(a)drgeo.eu> wrote: > > Oh, for the record, regarding the issue discussed bellow about determining the NIC IP. > > When a server broadcast an UDP message, the client receiving it can fetch the server NIC IP from the result returned by the #receiveUDPDataInto: message. > > I only tested it on the same workstation, but I guess it work as the UDP datagram is encapsulated in an IP packet. > > Hilaire > > Le 14/05/2018 Ã 11:28, Henrik Sperre Johansen a Ã©crit : >> That's the "old" ipv4 primitive. >> The "new" ipv4/ipv6 primitive >> (sqResolverGetAddressInfoHostSizeServiceSizeFlagsFamilyTypeProtocol) uses >> getaddrinfo instead, and lets you interate over the results; this is what >> the SSDP package tries to do when you specify allLocalV4Addresses. >> >> It's unreliable because: >> 1) Finding the correct hostname can be difficult (iirc, some vm's fail the >> hostname prim, and always returns the fallback 'localhost') >> 2) It uses DNS lookups, which can both be slow, and depend on network >> configuration. >> 3) The correct domain to use when you want aggregated results over multiple >> interfaces (.local? nothing?) differs from platform to platform. (iirc, OSX >> only ever returns a single entry if adding .local) >> >> "However when I activate a second network interface, this last one returns >> an empty collection" >> I just tested on a Windows 10 machine with 6.1 release (Pharo 6.1 >> stable\Pharo.exe >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017), for me the statement >> part := SSDPParticipant new. >> part allLocalV4Addresses. >> correctly returns 1/2/1 addresses when connecting/disconnecting to a >> wireless network :/ >> >> Why lookup would start to fail when you activate an interface, and stay >> failing after you remove it, I couldn't say, but I can say that >> SSDPParticipant >> hostName returning names that DNS won't resolve properly >> for some or another reason has been a problem I've encountered before. > > -- > Dr. Geo > http://drgeo.eu > > >

May 24, 2018

Re: [Pharo-users] How to LAN feature

by Hilaire

Oh, for the record, regarding the issue discussed bellow about determining the NIC IP. When a server broadcast an UDP message, the client receiving it can fetch the server NIC IP from the result returned by the #receiveUDPDataInto: message. I only tested it on the same workstation, but I guess it work as the UDP datagram is encapsulated in an IP packet. Hilaire Le 14/05/2018 Ã 11:28, Henrik Sperre Johansen a Ã©critÂ : > That's the "old" ipv4 primitive. > The "new" ipv4/ipv6 primitive > (sqResolverGetAddressInfoHostSizeServiceSizeFlagsFamilyTypeProtocol) uses > getaddrinfo instead, and lets you interate over the results; this is what > the SSDP package tries to do when you specify allLocalV4Addresses. > > It's unreliable because: > 1) Finding the correct hostname can be difficult (iirc, some vm's fail the > hostname prim, and always returns the fallback 'localhost') > 2) It uses DNS lookups, which can both be slow, and depend on network > configuration. > 3) The correct domain to use when you want aggregated results over multiple > interfaces (.local? nothing?) differs from platform to platform. (iirc, OSX > only ever returns a single entry if adding .local) > > "However when I activate a second network interface, this last one returns > an empty collection" > I just tested on a Windows 10 machine with 6.1 release (Pharo 6.1 > stable\Pharo.exe > CoInterpreter VMMaker.oscog-eem.2254 uuid: > 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017), for me the statement > part := SSDPParticipant new. > part allLocalV4Addresses. > correctly returns 1/2/1 addresses when connecting/disconnecting to a > wireless network :/ > > Why lookup would start to fail when you activate an interface, and stay > failing after you remove it, I couldn't say, but I can say that > SSDPParticipant >> hostName returning names that DNS won't resolve properly > for some or another reason has been a problem I've encountered before. -- Dr. Geo http://drgeo.eu

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by Guillermo Polito

Hi Peter, would you mind testing latest Pharo7 also and telling us if you see some similar problem? Several things were improved in the freetype bindings since Pharo6, and probably this is fixed?. Tx, Guille On Thu, May 24, 2018 at 2:06 PM, peter yoo <onionmixer(a)gmail.com> wrote: > hello! im new install ubuntu 18.04 LTS to my desktop. but pharo cannot run. > > look a attached png then know the problem. cannot using wirh wayland > system now? > > maybe guess.... because freetype.... have a solution then help to me > please. > > -- > http://lookandwalk.com http://looknw.com | http://onionmixer.net > peter yoo(Jonghwa Yoo). ROK > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 24, 2018

im using pharo in wayland system.

by peter yoo

hello! im new install ubuntu 18.04 LTS to my desktop. but pharo cannot run. look a attached png then know the problem. cannot using wirh wayland system now? maybe guess.... because freetype.... have a solution then help to me please. -- http://lookandwalk.com http://looknw.com | http://onionmixer.net peter yoo(Jonghwa Yoo). ROK

May 24, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Steffen MÃ¤rcker

Hi, now I've observed the same issue. It might be related to context switching, since introducing a delay has a similar effect. Consider: | FE_TONEAREST FE_DOWNWARD FE_UPWARD FE_TOWARDZERO | FE_TONEAREST := 16r0000. FE_DOWNWARD := 16r0400. FE_UPWARD := 16r0800. FE_TOWARDZERO := 16r0C00. "For some reasons we have to call fegetround once." "c := LibC new fegetround." LibC new fesetround: FE_DOWNWARD. (Delay forSeconds: 1) wait. v1 := 1.0/10.0. LibC new fesetround: FE_UPWARD. v2 := 1.0/10.0. LibC new fesetround: FE_TONEAREST. v1 < v2. If the delay is inserted, the script evaluates to false. Using the same LibC-instance or creating a new one does not seem to change anything here. Interestingly, a similar approach in VisualWorks does not show this issue yet. Actually, I expect the FE_* macros to be platform/implementation dependent, as suggested here: http://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/c/… Best, Steffen Am .05.2018, 11:57 Uhr, schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > What is really strange is when I print the following lines, I obtain > 2048: > > current := LibC uniqueInstance fegetround. > LibC uniqueInstance fesetround: 2048. > LibC uniqueInstance fegetround. > > and 0 when I remove the first line : > LibC uniqueInstance fesetround: 2048. > LibC uniqueInstance fegetround. > > > > On Thu, May 24, 2018 at 10:37 AM Serge Stinckwich < > serge.stinckwich(a)gmail.com> wrote: > >> >> >> On Thu, May 24, 2018 at 10:31 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: >> >>> I actually made progress: It works like a charm! Basically, I >>> implemented >>> the same code as you. Testing is straightforward (using the constant >>> values from libc): >>> >>> current := LibC fegetround. >>> LibC fesetround: FE_DOWNWARDS. >>> v1 := 1.0/10.0. >>> LibC feesetround: FE_UPWARDS. >>> v2 := 1.0/10.0. >>> LibC feesetround: current. >>> v1 < v2. "true" >>> >>> > âbut apparently nothing happens when you do : >>> > LibC uniqueInstance fesetround: 1024. >>> > LibC uniqueInstance fegetround. >>> > always return 0.â >>> >>> This is expected, since the fesetround function returns 0 only if the >>> set >>> operation was successful. >>> >>> >> âI was talking about fgetround function. >> â Can you check the value returns by your fegetround function ?â >> >> Constants values are not dependent of the platform ?â >> >> âCan you commit yr code to Pharo 7.0 or if there is no interest for this >> to PolyMath ?â >> âThank you.â >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (SU/IRD/UY1) >> "Programs must be written for people to read, and only incidentally for >> machines to execute."http://www.doesnotunderstand.org/ >> >

May 24, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Serge Stinckwich

What is really strange is when I print the following lines, I obtain 2048: current := LibC uniqueInstance fegetround. LibC uniqueInstance fesetround: 2048. LibC uniqueInstance fegetround. and 0 when I remove the first line : LibC uniqueInstance fesetround: 2048. LibC uniqueInstance fegetround. On Thu, May 24, 2018 at 10:37 AM Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > > > On Thu, May 24, 2018 at 10:31 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> I actually made progress: It works like a charm! Basically, I >> implemented >> the same code as you. Testing is straightforward (using the constant >> values from libc): >> >> current := LibC fegetround. >> LibC fesetround: FE_DOWNWARDS. >> v1 := 1.0/10.0. >> LibC feesetround: FE_UPWARDS. >> v2 := 1.0/10.0. >> LibC feesetround: current. >> v1 < v2. "true" >> >> > âbut apparently nothing happens when you do : >> > LibC uniqueInstance fesetround: 1024. >> > LibC uniqueInstance fegetround. >> > always return 0.â >> >> This is expected, since the fesetround function returns 0 only if the >> set >> operation was successful. >> >> > âI was talking about fgetround function. > â Can you check the value returns by your fegetround function ?â > > Constants values are not dependent of the platform ?â > > âCan you commit yr code to Pharo 7.0 or if there is no interest for this > to PolyMath ?â > âThank you.â > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ > -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

May 24, 2018