That's probably that the font used to render window titles is different
than the one used for text...
Check here:
http://pharo.org/contribute
All the information for issue reporting should be there :)
Tx!
On Fri, May 25, 2018 at 4:09 AM, peter yoo wrote:
> so..
so.. application location include korean charactor then broken title string
in pharo window.
(of course ubuntu 18.04 with gnome env)
broken title is "바탕화면". it's ok? or where to report?
look a attached file please.
--
http://lookandwalk.com http://looknw.com | http://onionmixer.net
peter
to Thierry. hm... look your reply then... im unzip new pure pharo and test.
ok now.
감사합니다. Thierry :D
Dear Pharoers,
I'm just starting out with Pharo 6.1, and I'm trying to use code completion
to interactively explore various objects and their messages. However, I'm
having difficulties doing this efficiently - I think I must be missing
something obvious, and I hope you can point me in the right
Thanks. Command line didn't occur to me. Functional fixedness.
Evan
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Even,
what Pharo version are you using? What Iceberg version (the one that comes
by default)?
If you're in Pharo 6 with the default iceberg version, I'd suggest you to:
- update iceberg
- or just fix it from the command line
$ git reset --hard HEAD~1
should do what you want.
If you
Le 24/05/2018 à 18:16, peter yoo a écrit :
thank you. Thierry :D
Ok, I checked again, now that I'm back with a 18.04 system.
I have SourceCodePro and SourceSansPro as fonts.
Thierry
> On 24 May 2018, at 19:28, Hilaire wrote:
>
> Hi,
>
> With this code, the ConnectionTimedOut exception is never handled:
>
> | socket data |
> socket := Socket newUDP.
> socket setPort: 51284.
> socket waitForDataFor: 5.
> data := ByteArray new: 100.
> [[socket
Hi,
With this code, the ConnectionTimedOut exception is never handled:
| socket data |
socket := Socket newUDP.
socket setPort: 51284.
socket waitForDataFor: 5.
data := ByteArray new: 100.
[[socket receiveUDPDataInto: data]
on: Error
do: ['Catched error, closing socket' crLog. socket
thank you. Thierry :D
Le jeu. 24 mai 2018 16:23, peter yoo 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
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
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
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
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 wrote:
>
> Oh, for the record, regarding the issue discussed bellow about
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
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 wrote:
> hello! im
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 := 16r.
FE_DOWNWARD := 16r0400.
FE_UPWARD := 16r0800.
FE_TOWARDZERO
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.
Aaand, I've updated
https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo
On Thu, May 24, 2018 at 11:34 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:
> https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies)
>
On Thu, May 24, 2018 at 10:31 AM Steffen Märcker 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:
https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies)
https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging
On Thu, May 24, 2018 at 11:30 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:
> Hi,
>
> I'll take some minutes to provide an answer as detailed as possible to
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.
Hi,
I'll take some minutes to provide an answer as detailed as possible to all
questions in this mail, and to the ones in the mails before.
But first, since I know most people only read the first lines of mails :P,
if you find any concrete iceberg issues, please report them in
On Wed, May 23, 2018 at 3:39 PM Steffen Märcker wrote:
> Hi Henry,
>
> > [...] it might be possible to try to do this with FFI only?
>
> If I understand you correctly, I could use FFI to call an external lib to
> perform the actual computation according to the rounding mode,
I took a look of course. Thanks.
At my basic level of knowledge, I found the articles on the Pharo books
and the basic Tests on Socket very helpful.
Hilaire
Le 23/05/2018 à 17:42, N. Bouraqadi a écrit :
Note that the package includes tests that show that the broadcast
working :-)
Thanx
Hi Henrik,
Le 22/05/2018 à 10:57, Henrik Sperre Johansen a écrit :
With UDP, there is no connection concept, so I'd reckon
waitForConnectionFor: is what gives you a TimeOut error...
The #waitForConnectionFor: message seems not to be the issue. I was
doing something apparently stupid: I
Thanks!
> On 24 May 2018, at 10:34, Guillermo Polito wrote:
>
> AAAnd, I've uploaded some of this things to Iceberg's documentation.
>
> How to contribute to Iceberg:
> https://github.com/pharo-vcs/iceberg/wiki/Contributing-to-Iceberg
> Metacello support:
AAAnd, I've uploaded some of this things to Iceberg's documentation.
How to contribute to Iceberg:
https://github.com/pharo-vcs/iceberg/wiki/Contributing-to-Iceberg
Metacello support:
https://github.com/pharo-vcs/iceberg/wiki/Metacello-Support
Branching and merging:
On Thu, May 24, 2018 at 9:51 AM, Guillermo Polito wrote:
> Hi Tim,
>
> On Wed, May 23, 2018 at 6:32 PM, Tim Mackinnon wrote:
>
>> Guille - the text reads very well, I’ll try and look at the videos later.
>>
>
> Good!
>
>
>> I just submitted a PR to
Hi Tim,
On Wed, May 23, 2018 at 6:32 PM, Tim Mackinnon wrote:
> Guille - the text reads very well, I’ll try and look at the videos later.
>
Good!
> I just submitted a PR to pharo to try and get the contributions text
> pointing to the “newer way” so that people don’t get
Big thanks :) If you have any question regarding the stream changes, go on
On Wed, May 23, 2018 at 10:52 PM, Eric Gade wrote:
> Thanks, Sven. I'll switch over to Pharo 7a and continue my efforts there.
> When I have something worth a damn I'll submit a PR according to the
32 matches
Mail list logo