2009/10/15 Andy Wingo :
> The ports C interface is rather crufty, as you have found :) Do you have
> any suggestions, or a patch? Keep in mind that we need to maintain
> backwards compatibility with these interfaces.
What do you think about documented additional function like this?
--
SCM
scm_c_fd
2009/10/14 Stanislav Ievlev :
> As I understand you should mark scm_fdes_to_port as a deprecated and
> don't use it in own code (e.g. in socket.c).
Ooops, I'm wrong.
scm_fdes_to_port works is like "scm_C_fdopen", however function name
is not good ;)
As I understand you should mark scm_fdes_to_port as a deprecated and
don't use it in own code (e.g. in socket.c).
2009/10/14 Stanislav Ievlev :
> Greetings!
>
> There are several functions exists to convert file descriptor into guile port:
> * scm_fdes_to_ports - search fo
is the difference between scm_fdes_to_port and scm_fdopen? What
function should I use?
Have you any plans to made this API simpler?
--
With best regards
Stanislav Ievlev.
2009/3/14 Neil Jerram
> Stanislav Ievlev writes:
>
> > It's very strange but I see an only one thread. full Backtrace in attach.
>
> That is indeed odd. Are you using GDB, and the "info threads"
> command, and it lists only one thread?
Yes, "info threads" shows me only one thread.
2009/3/14 Neil Jerram
> Stanislav Ievlev writes:
>
> > It's very strange but I see an only one thread. full Backtrace in attach.
>
> That is indeed odd. Are you using GDB, and the "info threads"
> command, and it lists only one thread?
>
> >
It's very strange but I see an only one thread. full Backtrace in attach.
2009/3/12 Neil Jerram
> Stanislav Ievlev writes:
>
> > Greetings!
> >
> > On my 2.6.18 kernel guile (latest snapshot from git, branch-release-1.8
> head)
> > in some situations
d9 in scm_i_gc () from /usr/lib64/libguile.so.17
#5 0x2b4ba22ac338 in scm_gc_for_newcell () from
/usr/lib64/libguile.so.17
#6 0x2b4ba22cc86f in scm_cons () from /usr/lib64/libguile.so.17
--
How can I debug and solve this problem?
--
With best results
Stanislav Ievlev.
10 декабря 2008 г. 1:17 пользователь Neil Jerram
<[EMAIL PROTECTED]>написал:
> 2008/12/8 Stanislav Ievlev <[EMAIL PROTECTED]>:
> >
> > I think this is a bug, because different symbols has different external
> > representation ;)
>
> Not sure I'm under
This is a guile 1.8.5
2008/12/8 Stanislav Ievlev <[EMAIL PROTECTED]>
>
>
> 2008/12/8 Stanislav Ievlev <[EMAIL PROTECTED]>
>
>> Greetings!
>>
>> Why results of (display) and (write) functions on same utf-8 string are
>> too different?
>
> It&
2008/12/8 Stanislav Ievlev <[EMAIL PROTECTED]>
> Greetings!
>
> Why results of (display) and (write) functions on same utf-8 string are too
> different?
It's very strange that one symbols ('о' - russian 'o') I see without
changes, bu
Greetings!
Why results of (display) and (write) functions on same utf-8 string are too
different?
--
$ guile
guile> (define a "строка")
guile> (display a)
строкаguile> (write a)
"�x81�x82�x80ока"guile>
--
--
With best regards
Stanislav Ievlev.
n is to create a simple wrapper like this:
--
$ gcc -O1 l2.c
[EMAIL PROTECTED] zzz]$ cat l2.c
#include
#include
#include
#include
#define CHECK_OR_IGNORE(x) if (x) error(EXIT_FAILURE,errno,#x)
int main()
{
char c;
CHECK_OR_IGNORE(write(1,&c,1));
return 0;
}
On Thu, Oct 12, 2006 at 02:58:58PM +0200, Ludovic Court?s wrote:
> Hi,
>
> Stanislav Ievlev <[EMAIL PROTECTED]> writes:
>
> > On Tue, Oct 10, 2006 at 10:23:31AM +0200, Ludovic Court?s wrote:
> >> Hi,
> >>
> >> Stanislav Ievlev <[EMAIL PR
On Tue, Oct 10, 2006 at 10:23:31AM +0200, Ludovic Court?s wrote:
> Hi,
>
> Stanislav Ievlev <[EMAIL PROTECTED]> writes:
>
> > : In expression (vector-length syntmp-x-1008):
> > : Stack overflow
>
> Did you compile with `-O0'? If so, make sure yo
I see (1.7.91) was work well.
There is also a build log from our build system in attach.
--
With best regards
Stanislav Ievlev.
ALT Linux Team.
build.log.bz2
Description: BZip2 compressed data
___
Guile-devel mailing list
Guile-devel@gnu.org
http
On Sun, Feb 26, 2006 at 12:58:46PM +0300, Stanislav Ievlev wrote:
> Hi!
>
> What about this problem?
Problem was in hidden select in g_main_loop (thanks to myself)
We really need enter_guile(), leave_guile() for such cases.
with-guile/without-guile will not work.
Are you planning to
Hi!
What about this problem?
--
Stanislav Ievlev.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
= 23004
23005 poll([{fd=10, events=POLLIN}], 1, 2000) = 0
23005 getppid() = 23004
23005 poll([{fd=10, events=POLLIN}], 1, 2000) = 0
23005 getppid() = 23004
23005 poll([{fd=10, events=POLLIN}], 1, 2000) = 0
--
---
With best regards
Stanislav Ievle
On Sat, Feb 18, 2006 at 11:51:48AM -0500, Ken Raeburn wrote:
> On Feb 17, 2006, at 06:18, Stanislav Ievlev wrote:
>
> >Greetings!
> >
> >It is unable to call callback from thread in guile extension.
>
> Does it work if you use scm_with_guile in that thread, as desc
--
how to reproduce:
$gcc -fpic -lpthread dbus.c -shared -o lguile-thread.so
---
guile
guile> (dynamic-call "scm_init_test" (dynamic-link "libguile-thread.so"))
guile> (define cb (lambda() (write "zzz!\n")))
g
21 matches
Mail list logo
