Nala Ginrut writes:
> I know it's not the best implementation, I didn't consider the
> multi-threads situation.
Yes, unfortunately there is no way to set the locale on a per-thread
basis. This is a limitation of the C library.
> in many protocols, it needs
> the result of strftime be in
BT Templeton writes:
> Mark H Weaver writes:
>
>> Hello all,
>>
>> I was chatting with the folks working on Python-on-Guile, and it seems
>> clear that they need the ability to create GOOPS objects that can
>> emulate procedures. Otherwise they will probably end up creating an
>> entirely separ
Mark H Weaver writes:
> Hello all,
>
> I was chatting with the folks working on Python-on-Guile, and it seems
> clear that they need the ability to create GOOPS objects that can
> emulate procedures. Otherwise they will probably end up creating an
> entirely separate object system for Python, wh
I know it's not the best implementation, I didn't consider the
multi-threads situation.
But it's food of thinking.
Regards.
On Sat, Mar 24, 2012 at 12:37 PM, Nala Ginrut wrote:
> Hi folks!
> I encountered a bug in my project for these days. Finally I realized it's
> because of my locale is zh_C
Hi folks!
I encountered a bug in my project for these days. Finally I realized it's
because of my locale is zh_CN.UTF-8 in default. But in many protocols, it
needs
the result of strftime be in English. Anyway, I think there should be an
elegant way to change locale temperately. So I think maybe wit
hi Mark!
I think this will enhance our multi-language feature. Other inner language
may need it later.
And I don't see any harm with this generic-apply.
Personally, I wish this could be done soon. Because I'm interested in
adding new inner language too. ;-)
Regards.
On Sat, Mar 24, 2012 at 3:02 A
Hello all,
I was chatting with the folks working on Python-on-Guile, and it seems
clear that they need the ability to create GOOPS objects that can
emulate procedures. Otherwise they will probably end up creating an
entirely separate object system for Python, which would obviously be
suboptimal.
> Hi,
>
> I don't know why this would not have been stumbled over before,
> but I'd like to confirm that in the Guile string processing code,
> you only delete or alter characters in the 0x80 to 0xFF range, correct?
> I can still rely on 0x01 through 0x1F and 0x7F being left alone, yes?
> Thanks!
Hi,
Andy Wingo skribis:
> On Wed 21 Mar 2012 22:02, l...@gnu.org (Ludovic Courtès) writes:
>
>>> See c05805a4ea764dec5a0559edefcdfb9761191d07 in stable-2.0 for the
>>> gnarly details. The summary is that applicable smobs were being leaked,
>>> because they were referenced in the values of weak-
Hi,
I don't know why this would not have been stumbled over before,
but I'd like to confirm that in the Guile string processing code,
you only delete or alter characters in the 0x80 to 0xFF range, correct?
I can still rely on 0x01 through 0x1F and 0x7F being left alone, yes?
Thanks!
- Bruce
Hi :)
On Wed 21 Mar 2012 22:26, l...@gnu.org (Ludovic Courtès) writes:
> Without exposing ‘pthread_atfork’, how would you suggest making user
> code “fork-safe”? A use case would be reviving the futures thread pool
> after ‘fork’.
Humm, just tried to think about it for 10 minutes or so and I'm
On Fri 23 Mar 2012 03:00, Nala Ginrut writes:
> Cool~but I think it didn't support Non-Block IO, right?
It does support non-blocking I/O, yes. fdes->eport sets O_NONBLOCK on
the fd. Any time an operation would block causes the operation to
suspend the current continuation, and ask the epoll lo
On Fri 23 Mar 2012 02:47, Nala Ginrut writes:
> Besides, I think we need "write bytevector from port and return the
> successful size".
That's what (ice-9 nio) from wip-ethreads implements -- the primitives.
It's a little confusing as things have changed some since I first posted
wip-nio. Summ
Heya :)
On Wed 21 Mar 2012 23:39, l...@gnu.org (Ludovic Courtès) writes:
> I had a quick look at ‘wip-nio’, and here are initial comments.
Thanks for the feedback!
> • epoll is Linux-specific. Any idea how a more multi-platform API
> could be provided? I guess libevent could be used, bu
On Thu 22 Mar 2012 22:36, Neil Jerram writes:
> It seems like the module has to anticipate the main loop infrastructure
> that any using programs will use - which isn't a nice solution.
How about, you write your code in such a way that it deals with eports.
You could surround your code in a prom
15 matches
Mail list logo