syllable-developer — General developer discussion and questions

[Syllable-developer] FOSDEM booth/devroom sharing

[F. R. <re...@fr...>]

(sent to AROS (please forward, I'm not on the dev list), ReactOS, 
Syllable, CCed to Haiku)

Hello,
I'm a Haiku developer, <http://haiku-os.org>
and I would like to propose sharing a devroom, eventually a booth at 
FOSDEM with some other FOSS OS projects.

I sent to the mailing lists as I couldn't identify a specific contact, 
and I don't know how much centralized each project is.

Last year we had our own booth at FOSDEM (we it shared with an ERP 
software),
I really enjoyed the event, and would like to also get a devroom this 
year.
But I'm not sure we will have enough people to animate it all the time 
(currently 3 or 4), plus we'd still have a stand to look after.

http://www.haiku-os.org/blog/mmu_man/2008-02-25/hello_from_fosdem

I know we shared a booth at last LinuxWorld with ReactOS and I heard it 
was interesting:
http://www.haiku-os.org/blog/umccullough/2008-08-06/day_1_at_linuxworld_2008_a_solid_start
http://www.haiku-os.org/blog/umccullough/2008-08-07/day_2_at_linuxworld_2008_more_of_the_same

As the deadline for booth and devroom application approaches (it's 
before 22 nov.), I was thinking about sharing a devroom that could be 
called "alternative OSes", "grep -v GNU/Linux" or alike, with other 
projects.
This way we could all get a devroom with fewer people to man it.

As for our project, we could have talks and hacking sessions on many 
subjects, from architecture and design to installation, and specific 
things like the using the FreePascal port, porting applications, using 
replicants (like NetSurf).

We could also have common talks, about the platforms we support, our 
design and goals.

And if needed we could probably also share a booth with another project 
I suppose, last year we shared with a totally different software.

I'll be mailing a booth and devroom request tomorrow precising it, 
before it's too late.

François.

Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

2008/11/1 Kristian Van Der Vliet <va...@li...>:
> No, this is very helpful. It's nice to have some feedback on this sort
> of level. Without it I can't improve Syllable :)

Good to know you're open to feedback :-)

Stefano

Re: [Syllable-developer] Porting help

[Kristian V. D. V. <va...@li...>]

On Sat, 2008-11-01 at 15:39 +0100, Stephan Assmus wrote:
> Kristian Van Der Vliet wrote:
> > On Sat, 2008-11-01 at 14:44 +0100, Stefano D'Angelo wrote:
> > > 2008/11/1 Kristian Van Der Vliet <va...@li...>:
> > > > On Sat, 2008-11-01 at 11:42 +0100, Stefano D'Angelo wrote:
> > > >> I investigated a bit into Syllable's source code and it seems like 
> > > >> some weird stuff is going on... First, in pthread_exit(), this cycle 
> > > >> seems to be broken:
> > > >>
> > > >>   231         while ( cleanup )
> > > >>   232         {
> > > >>   233                 if ( cleanup->routine )
> > > >>   234                         (*cleanup->routine) (cleanup->arg);
> > > >>   235                 cleanup = cleanup->prev;
> > > >>   236                 free( cleanup );
> > > >>   237         }
> > > >>
> > > >> since after the first loop, cleanup points to a freed memory 
> > > >> location, which shouldn't be considered valid any more (unless you 
> > > >> have very very strange memory handling routines/conventions, but I 
> > > >> doubt that).
> > > >
> > > > Believe it or not that loop is actually O.K. It works backwards 
> > > > through the list, calling the cleanup handlers and then freeing the 
> > > > structures as it goes. For the first item in the list, prev will be 
> > > > NULL and free(NULL) is a valid no-op, and the loop will then exit. I 
> > > > admit it is non-obvious.
> > 
> > Anthony has pointed out to me that there is an issue here in that the 
> > first cleanup structure in the list is never free'd, which is a valid 
> > problem here.
> 
> No, it is really more broken than that. After calling free(cleanup), the 
> pointer points to free()d memory, but you happly dereference it in the next 
> iteration of the loop.

Yes, you're right. I had some sort of mental disconnect and couldn't see
the deference in the next iteration. Stefanos original solution is
correct.

-- 
Vanders
http://www.syllable.org

Re: [Syllable-developer] Porting help

[Stephan A. <sup...@gm...>]

Kristian Van Der Vliet wrote:
> On Sat, 2008-11-01 at 14:44 +0100, Stefano D'Angelo wrote:
> > 2008/11/1 Kristian Van Der Vliet <va...@li...>:
> > > On Sat, 2008-11-01 at 11:42 +0100, Stefano D'Angelo wrote:
> > >> I investigated a bit into Syllable's source code and it seems like 
> > >> some weird stuff is going on... First, in pthread_exit(), this cycle 
> > >> seems to be broken:
> > >>
> > >>   231         while ( cleanup )
> > >>   232         {
> > >>   233                 if ( cleanup->routine )
> > >>   234                         (*cleanup->routine) (cleanup->arg);
> > >>   235                 cleanup = cleanup->prev;
> > >>   236                 free( cleanup );
> > >>   237         }
> > >>
> > >> since after the first loop, cleanup points to a freed memory 
> > >> location, which shouldn't be considered valid any more (unless you 
> > >> have very very strange memory handling routines/conventions, but I 
> > >> doubt that).
> > >
> > > Believe it or not that loop is actually O.K. It works backwards 
> > > through the list, calling the cleanup handlers and then freeing the 
> > > structures as it goes. For the first item in the list, prev will be 
> > > NULL and free(NULL) is a valid no-op, and the loop will then exit. I 
> > > admit it is non-obvious.
> 
> Anthony has pointed out to me that there is an issue here in that the 
> first cleanup structure in the list is never free'd, which is a valid 
> problem here.

No, it is really more broken than that. After calling free(cleanup), the 
pointer points to free()d memory, but you happly dereference it in the next 
iteration of the loop.

Best regards,
-Stephan

Re: [Syllable-developer] Porting help

[Kristian V. D. V. <va...@li...>]

On Sat, 2008-11-01 at 14:44 +0100, Stefano D'Angelo wrote:
> 2008/11/1 Kristian Van Der Vliet <va...@li...>:
> > On Sat, 2008-11-01 at 11:42 +0100, Stefano D'Angelo wrote:
> >> I investigated a bit into Syllable's source code and it seems like
> >> some weird stuff is going on... First, in pthread_exit(), this cycle
> >> seems to be broken:
> >>
> >>   231         while ( cleanup )
> >>   232         {
> >>   233                 if ( cleanup->routine )
> >>   234                         (*cleanup->routine) (cleanup->arg);
> >>   235                 cleanup = cleanup->prev;
> >>   236                 free( cleanup );
> >>   237         }
> >>
> >> since after the first loop, cleanup points to a freed memory location,
> >> which shouldn't be considered valid any more (unless you have very
> >> very strange memory handling routines/conventions, but I doubt that).
> >
> > Believe it or not that loop is actually O.K. It works backwards through
> > the list, calling the cleanup handlers and then freeing the structures
> > as it goes. For the first item in the list, prev will be NULL and
> > free(NULL) is a valid no-op, and the loop will then exit. I admit it is
> > non-obvious.

Anthony has pointed out to me that there is an issue here in that the
first cleanup structure in the list is never free'd, which is a valid
problem here.

>> Going back to the original problem, it seems like pthread_exit()
> >> completely destroys the thread, which is not a POSIX-compliant
> >> behaviour, since it won't be found by pthread_join()s happening after
> >> the thread has terminated.
> >>
> >> This would be ok for PTHREAD_CREATE_DETACHED threads, but the POSIX
> >> standards states that the default detachstate is
> >> PTHREAD_CREATE_JOINABLE.
> >
> > The OpenGroup spec says:
> >
> > "The pthread_join() function suspends execution of the calling thread
> > until the target thread terminates, unless the target thread has already
> > terminated. On return from a successful pthread_join() call with a
> > non-NULL value_ptr argument, the value passed to pthread_exit() by the
> > terminating thread is made available in the location referenced by
> > value_ptr. When a pthread_join() returns successfully, the target thread
> > has been terminated. The results of multiple simultaneous calls to
> > pthread_join() specifying the same target thread are undefined. If the
> > thread calling pthread_join() is canceled, then the target thread will
> > not be detached.
> >
> > [ESRCH]
> >        No thread could be found corresponding to that specified by the
> >        given thread ID."
> >
> > which is what the current implementation does: if pthread_join() is
> > called on a thread that has already called pthread_exit() it returns
> > ESRCH. However it seems I have been tripped up by "When a pthread_join()
> > returns successfully, the target thread has been terminated."! Reading
> > that now my interpretation is that pthread_join() should return
> > immediately when called on a thread that has exited, rather than
> > returning ESRCH.
> >
> > I *think* there is a way to fix this, sort of: wait_for_thread() will
> > return -ECHILD if the target thread does not exist, which can be
> > interpreted as "Thread has exited". However there is then no way to
> > detect cases where the thread ID is invalid I.e. to return ESRCH, but
> > this would seem to be a less important edge case.
> 
> Well... it seems like the POSIX standard is a bit ambiguous (as usual
> :-P), but looking around I've always seen it implemented "the other
> way": pthread_join() will return 0 on terminated threads (that's for
> sure on Linux, FreeBSD, DragonFlyBSD and Haiku).
> 
> However, it is my understanding that the original meaning of the
> standard is that you can have two types of threads:
> * PTHREAD_CREATE_DETACHED threads, which you just can't join or detach
> (thus can't get their return value) - those threads should be
> completely destroyed when they call pthread_exit();
> * PTHREAD_CREATE_JOINABLE threads (the default), which the system
> should keep their return value (hence reference to them) in memory
> until pthread_join() is called.
> 
> I don't think any other interpration, even if valid according to the
> "literal standard", makes much sense.

No I think you're right, otherwise it's a potential race condition
between one thread exiting and the other calling join: the joining
thread could interpret the return from ESRCH as a fatal error and abort,
when it isn't.

> Don't misunderstand, I'm not trying to dictate what you should do, I'm
> just trying to help you (and me, porting that stuff).

No, this is very helpful. It's nice to have some feedback on this sort
of level. Without it I can't improve Syllable :)

-- 
Vanders
http://www.syllable.org

Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

2008/11/1 Kristian Van Der Vliet <va...@li...>:
> On Sat, 2008-11-01 at 11:42 +0100, Stefano D'Angelo wrote:
>> I investigated a bit into Syllable's source code and it seems like
>> some weird stuff is going on... First, in pthread_exit(), this cycle
>> seems to be broken:
>>
>>   231         while ( cleanup )
>>   232         {
>>   233                 if ( cleanup->routine )
>>   234                         (*cleanup->routine) (cleanup->arg);
>>   235                 cleanup = cleanup->prev;
>>   236                 free( cleanup );
>>   237         }
>>
>> since after the first loop, cleanup points to a freed memory location,
>> which shouldn't be considered valid any more (unless you have very
>> very strange memory handling routines/conventions, but I doubt that).
>
> Believe it or not that loop is actually O.K. It works backwards through
> the list, calling the cleanup handlers and then freeing the structures
> as it goes. For the first item in the list, prev will be NULL and
> free(NULL) is a valid no-op, and the loop will then exit. I admit it is
> non-obvious.
>
>> Going back to the original problem, it seems like pthread_exit()
>> completely destroys the thread, which is not a POSIX-compliant
>> behaviour, since it won't be found by pthread_join()s happening after
>> the thread has terminated.
>>
>> This would be ok for PTHREAD_CREATE_DETACHED threads, but the POSIX
>> standards states that the default detachstate is
>> PTHREAD_CREATE_JOINABLE.
>
> The OpenGroup spec says:
>
> "The pthread_join() function suspends execution of the calling thread
> until the target thread terminates, unless the target thread has already
> terminated. On return from a successful pthread_join() call with a
> non-NULL value_ptr argument, the value passed to pthread_exit() by the
> terminating thread is made available in the location referenced by
> value_ptr. When a pthread_join() returns successfully, the target thread
> has been terminated. The results of multiple simultaneous calls to
> pthread_join() specifying the same target thread are undefined. If the
> thread calling pthread_join() is canceled, then the target thread will
> not be detached.
>
> [ESRCH]
>        No thread could be found corresponding to that specified by the
>        given thread ID."
>
> which is what the current implementation does: if pthread_join() is
> called on a thread that has already called pthread_exit() it returns
> ESRCH. However it seems I have been tripped up by "When a pthread_join()
> returns successfully, the target thread has been terminated."! Reading
> that now my interpretation is that pthread_join() should return
> immediately when called on a thread that has exited, rather than
> returning ESRCH.
>
> I *think* there is a way to fix this, sort of: wait_for_thread() will
> return -ECHILD if the target thread does not exist, which can be
> interpreted as "Thread has exited". However there is then no way to
> detect cases where the thread ID is invalid I.e. to return ESRCH, but
> this would seem to be a less important edge case.

Well... it seems like the POSIX standard is a bit ambiguous (as usual
:-P), but looking around I've always seen it implemented "the other
way": pthread_join() will return 0 on terminated threads (that's for
sure on Linux, FreeBSD, DragonFlyBSD and Haiku).

However, it is my understanding that the original meaning of the
standard is that you can have two types of threads:
* PTHREAD_CREATE_DETACHED threads, which you just can't join or detach
(thus can't get their return value) - those threads should be
completely destroyed when they call pthread_exit();
* PTHREAD_CREATE_JOINABLE threads (the default), which the system
should keep their return value (hence reference to them) in memory
until pthread_join() is called.

I don't think any other interpration, even if valid according to the
"literal standard", makes much sense.

Don't misunderstand, I'm not trying to dictate what you should do, I'm
just trying to help you (and me, porting that stuff).

Stefano

Re: [Syllable-developer] Porting help

[Kristian V. D. V. <va...@li...>]

On Sat, 2008-11-01 at 11:42 +0100, Stefano D'Angelo wrote:
> I investigated a bit into Syllable's source code and it seems like
> some weird stuff is going on... First, in pthread_exit(), this cycle
> seems to be broken:
> 
>   231 	while ( cleanup )
>   232 	{
>   233 		if ( cleanup->routine )
>   234 			(*cleanup->routine) (cleanup->arg);
>   235 		cleanup = cleanup->prev;
>   236 		free( cleanup );
>   237 	}
> 
> since after the first loop, cleanup points to a freed memory location,
> which shouldn't be considered valid any more (unless you have very
> very strange memory handling routines/conventions, but I doubt that).

Believe it or not that loop is actually O.K. It works backwards through
the list, calling the cleanup handlers and then freeing the structures
as it goes. For the first item in the list, prev will be NULL and
free(NULL) is a valid no-op, and the loop will then exit. I admit it is
non-obvious.

> Going back to the original problem, it seems like pthread_exit()
> completely destroys the thread, which is not a POSIX-compliant
> behaviour, since it won't be found by pthread_join()s happening after
> the thread has terminated.
> 
> This would be ok for PTHREAD_CREATE_DETACHED threads, but the POSIX
> standards states that the default detachstate is
> PTHREAD_CREATE_JOINABLE.

The OpenGroup spec says:

"The pthread_join() function suspends execution of the calling thread
until the target thread terminates, unless the target thread has already
terminated. On return from a successful pthread_join() call with a
non-NULL value_ptr argument, the value passed to pthread_exit() by the
terminating thread is made available in the location referenced by
value_ptr. When a pthread_join() returns successfully, the target thread
has been terminated. The results of multiple simultaneous calls to
pthread_join() specifying the same target thread are undefined. If the
thread calling pthread_join() is canceled, then the target thread will
not be detached.

[ESRCH]
        No thread could be found corresponding to that specified by the
        given thread ID."

which is what the current implementation does: if pthread_join() is
called on a thread that has already called pthread_exit() it returns
ESRCH. However it seems I have been tripped up by "When a pthread_join()
returns successfully, the target thread has been terminated."! Reading
that now my interpretation is that pthread_join() should return
immediately when called on a thread that has exited, rather than
returning ESRCH.

I *think* there is a way to fix this, sort of: wait_for_thread() will
return -ECHILD if the target thread does not exist, which can be
interpreted as "Thread has exited". However there is then no way to
detect cases where the thread ID is invalid I.e. to return ESRCH, but
this would seem to be a less important edge case.

-- 
Vanders
http://www.syllable.org

Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

I investigated a bit into Syllable's source code and it seems like
some weird stuff is going on... First, in pthread_exit(), this cycle
seems to be broken:

  231 	while ( cleanup )
  232 	{
  233 		if ( cleanup->routine )
  234 			(*cleanup->routine) (cleanup->arg);
  235 		cleanup = cleanup->prev;
  236 		free( cleanup );
  237 	}

since after the first loop, cleanup points to a freed memory location,
which shouldn't be considered valid any more (unless you have very
very strange memory handling routines/conventions, but I doubt that).
At first glance I'd say it should be more like this:

while (cleanup)
{
        if (cleanup->routine)
                (*cleanup->routine) (cleanup->arg);
        tmp = cleanup;
        cleanup = cleanup->prev;
        free(tmp);
}

Going back to the original problem, it seems like pthread_exit()
completely destroys the thread, which is not a POSIX-compliant
behaviour, since it won't be found by pthread_join()s happening after
the thread has terminated.

This would be ok for PTHREAD_CREATE_DETACHED threads, but the POSIX
standards states that the default detachstate is
PTHREAD_CREATE_JOINABLE.

Stefano

Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

2008/10/26 Kristian Van Der Vliet <va...@li...>:
>> - the library you gave is name libpthread.so.2 while
>> /system/libraries/libpthread.so linked to
>> /system/libraries/libpthread.so.1 (using Syllable 0.6.5) - I guess
>> this implies that my stuff will only work with Syllable >= 0.6.6?
>
> Yes, but we do ship an ABI compatible libpthread.so.1 and I could &
> should apply the same fix there.

I don't really care, the only thing I care about is the "minimum
requirements" thing (so 0.6.6 should be it anyway)  ;-)

>> One of the two remaining problems goes like this:
>>
>> * the main thread allocates a mutex (ok)
>> * another thread locks it (ok)
>> * the same thread which locked it tries to unlock it, but
>> pthread_mutex_unlock() returns EPERM
>>
>> The mutex type is PTHREAD_MUTEX_ERRCHECK and it seems to always work
>> this way.
>
> Thanks, I'll look into it. Does it make any difference if the mutex is
> not MUTEX_ERRCHECK?

I tried without setting mutex type and it works correctly, but...
another problem came out: pthread_join() occasionally returning ESRCH.
Now, these tests work properly at least on Linux, so I'm pretty sure
that the code is valid.

In this case the test launches one hundred threads, lets them do some
concurrent insertion on a list, then waits for each one of them using
pthread_join(). pthread_join() is called inside a for loop which scans
the array of threads. The ESRCH return happens usually for the second
or third thread trying to be joined, so it does look like some kind of
bug.

Now, I understand these kind of stuff is quite hard to debug, so if
you want to reproduce these bugs on your own I can give you detailed
instructions on how to obtain and build the code I'm working on,
otherwise I can just keep up pinging you whenever I have problems. You
choose ;-)

>> The last problem is a fault of mine... however I noticed that dlsym()
>> sets errno to 131 when not finding some symbol (using strerror I get
>> "Unknown error - 131", but I see it is ENOSYM in errno.h), which is
>> probably fine since the POSIX standard doesn't seem to even mention
>> errno is the dlsym page... however, in case you are interested in
>> that, all other OSes I tried probably don't let dlsym set errno
>> (Windows/MSYS, Linux, BSDs), while the AIX man page for dlsym states:
>>
>> "If the named symbol is found, its address is returned. If the named
>> symbol is not found, NULL is returned and errno is set to 0."
>
> Hmm, that's what it should be doing, but libdl does use the native call
> get_symbol_address() which *may* set errno. libdl itself doesn't touch
> errno, so it wont clear errno to zero if get_symbol_address() fails.

As said, I think your way of doing things is perfectly valid and
POSIX-compatible, so I don't have problems with that. However some
buggy software could rely on this kind of behaviour, so it's up to you
whether you want to support those too. Just trying to help :-)

Stefano

Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

I was forgetting... other than those problems, the synchronization
test works fine, which is very likely to indicate that mutexes, at
least, work properly :-)

Stefano

Re: [Syllable-developer] Porting help

[Kristian V. D. V. <va...@li...>]

On Sun, 2008-10-26 at 04:16 +0100, Stefano D'Angelo wrote:
> 2008/10/24 Kristian Van Der Vliet <va...@li...>:
> > On Fri, 2008-10-24 at 13:31 +0100, Kristian Van Der Vliet wrote:
> >> I'll fix it in CVS later and email you a new libpthread if you like?
>  
> I will investigate on the remaining failures, in the meanwhile I
> noticed a couple of things:
> 
> - there seems to be no ldd script in Syllable - is this intentional?

Yes. The ldd script that is part of binutils uses ld.so, which we do not
have. Use readelf -d instead and look at the NEEDED items. The output
isn't as clear as ldd but shared libraries on Syllable rarely have
complex dependency trees.

> - the library you gave is name libpthread.so.2 while
> /system/libraries/libpthread.so linked to
> /system/libraries/libpthread.so.1 (using Syllable 0.6.5) - I guess
> this implies that my stuff will only work with Syllable >= 0.6.6?

Yes, but we do ship an ABI compatible libpthread.so.1 and I could &
should apply the same fix there.

> One of the two remaining problems goes like this:
>
> * the main thread allocates a mutex (ok)
> * another thread locks it (ok)
> * the same thread which locked it tries to unlock it, but
> pthread_mutex_unlock() returns EPERM
> 
> The mutex type is PTHREAD_MUTEX_ERRCHECK and it seems to always work
> this way.

Thanks, I'll look into it. Does it make any difference if the mutex is
not MUTEX_ERRCHECK?

> The last problem is a fault of mine... however I noticed that dlsym()
> sets errno to 131 when not finding some symbol (using strerror I get
> "Unknown error - 131", but I see it is ENOSYM in errno.h), which is
> probably fine since the POSIX standard doesn't seem to even mention
> errno is the dlsym page... however, in case you are interested in
> that, all other OSes I tried probably don't let dlsym set errno
> (Windows/MSYS, Linux, BSDs), while the AIX man page for dlsym states:
>
> "If the named symbol is found, its address is returned. If the named
> symbol is not found, NULL is returned and errno is set to 0."

Hmm, that's what it should be doing, but libdl does use the native call
get_symbol_address() which *may* set errno. libdl itself doesn't touch
errno, so it wont clear errno to zero if get_symbol_address() fails.

-- 
Vanders
http://www.syllable.org

Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

The last problem is a fault of mine... however I noticed that dlsym()
sets errno to 131 when not finding some symbol (using strerror I get
"Unknown error - 131", but I see it is ENOSYM in errno.h), which is
probably fine since the POSIX standard doesn't seem to even mention
errno is the dlsym page... however, in case you are interested in
that, all other OSes I tried probably don't let dlsym set errno
(Windows/MSYS, Linux, BSDs), while the AIX man page for dlsym states:

"If the named symbol is found, its address is returned. If the named
symbol is not found, NULL is returned and errno is set to 0."

Just to let you know ;-)

Stefano

Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

One of the two remaining problems goes like this:

* the main thread allocates a mutex (ok)
* another thread locks it (ok)
* the same thread which locked it tries to unlock it, but
pthread_mutex_unlock() returns EPERM

The mutex type is PTHREAD_MUTEX_ERRCHECK and it seems to always work this way.

The other problem is probably related to libdl, I will try to find out
more later.

Plus vi shows strange behaviour with home/end keys on Syllable (using
IT keyboard)... is that something configurable or what?

Stefano

Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

2008/10/24 Kristian Van Der Vliet <va...@li...>:
> On Fri, 2008-10-24 at 13:31 +0100, Kristian Van Der Vliet wrote:
>> I'll fix it in CVS later and email you a new libpthread if you like?
>
> Here it is. Un-7zip it and put the file in /system/libraries. You may
> need to reboot to force the new library to be loaded.
>
> I also found and fixed at least two other places where I'd made the same
> schoolboy error.

Ok, with the fixed library we go from 8/9 tests failed to 2/9 failures.

I will investigate on the remaining failures, in the meanwhile I
noticed a couple of things:

- there seems to be no ldd script in Syllable - is this intentional?
- the library you gave is name libpthread.so.2 while
/system/libraries/libpthread.so linked to
/system/libraries/libpthread.so.1 (using Syllable 0.6.5) - I guess
this implies that my stuff will only work with Syllable >= 0.6.6?

Stefano

Re: [Syllable-developer] Porting help

[Kristian V. D. V. <va...@li...>]

On Fri, 2008-10-24 at 13:31 +0100, Kristian Van Der Vliet wrote:
> I'll fix it in CVS later and email you a new libpthread if you like?

Here it is. Un-7zip it and put the file in /system/libraries. You may
need to reboot to force the new library to be loaded.

I also found and fixed at least two other places where I'd made the same
schoolboy error.

-- 
Vanders
http://www.syllable.org

Re: [Syllable-developer] Porting help

[Kristian V. D. V. <kri...@qu...>]

On Fri, 2008-10-24 at 11:41 +0100, Stefano D'Angelo wrote:
> So, my first problem is: I have the following line of code somewhere:
> 
> err = pthread_mutexattr_settype(&mutexattr, PTHREAD_MUTEX_ERRORCHECK);
> 
> which returns a non-0 value (probably EINVAL). Does this mean that
> Syllable does not recognize PTHREAD_MUTEX_ERRORCHECK as a valid POSIX
> mutex type or is there something else I should know?

It's a stupid bug in pthread_mutexattr_settype. Can you spot the problem?

if( ( type != PTHREAD_MUTEX_DEFAULT ) ||
    ( type != PTHREAD_MUTEX_ERRORCHECK ) ||
    ( type != PTHREAD_MUTEX_NORMAL ) ||
    ( type != PTHREAD_MUTEX_RECURSIVE ) )
      return( EINVAL );

Hmm, no I don't think that's quite right...

I'll fix it in CVS later and email you a new libpthread if you like?

-- 
Vanders
http://www.syllable.org

[Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

Hi all,

I'm trying to port my DSP framework to Syllable, or at least I'd like
to see it compiled and working on Syllable now and maybe write better
support in the future (both in the sense of build system/installation
and code).

So, my first problem is: I have the following line of code somewhere:

err = pthread_mutexattr_settype(&mutexattr, PTHREAD_MUTEX_ERRORCHECK);

which returns a non-0 value (probably EINVAL). Does this mean that
Syllable does not recognize PTHREAD_MUTEX_ERRORCHECK as a valid POSIX
mutex type or is there something else I should know?

Thanks,

Stefano

Re: [Syllable-developer] AltME

[<dem...@ne...>]

 Thanks, but that issue's already been resolved.

Dee Sharpe


 


 

-----Original Message-----
From: jon...@sy...
To: syl...@li...
Sent: Thu, 2 Oct 2008 1:25 am
Subject: Re: [Syllable-developer] AltME










> Would you mind resetting my password?

I dont think I can do that. You should probably ask Flemming instead.

/Jonas




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Syllable-developer mailing list
Syl...@li...
https://lists.sourceforge.net/lists/listinfo/syllable-developer



 

Re: [Syllable-developer] AltME

[<jon...@sy...>]

> Would you mind resetting my password?

I dont think I can do that. You should probably ask Flemming instead.

/Jonas

[Syllable-developer] AltME

[<dem...@ne...>]

Would you mind resetting my password?

Dee Sharpe

Re: [Syllable-developer] Just a few diffs (Chipset)

[makz z. <ma...@gm...>]

 Intel Corporation 82945G/GZ Integrated Graphics Controller

2008/9/15 martin trotter <tr...@sa...>

> -------- Original Message --------
> From: Kristian Van Der Vliet <va...@li...>
> Apparently from: syl...@li...
> To: syl...@li...
> Subject: Re: [Syllable-developer] Just a few diffs (Chipset)
> Date: Sun, 14 Sep 2008 22:52:28 +0100
>
> > On Sun, 2008-09-14 at 23:16 +0200, Flemming wrote:
> > > >On a side note, what's the common chipset vendors used by all of the
> > > >users/developers on this list.  I'd like for everyone to response
> > > >either on this list or email me directly. I can't use AltME at the
> > > >moment, so don't respond to this query there.
> > >
> > > SiS on my primary, and Intel (I think) on the Eee.
> >
> > Er, lets see. Mostly Intel ranging from i845 to x1300, then a Via KT400
> > and one nVidia nForce board that currently doesn't boot.
>
>
> Nforce 2 at the moment but thats going to be upgraded to a p35 or p45
> chipset soon.
>
> Intel chipset on an old x30 ibm thinkpad.
>
> VIA on a test machine
>
> Martin N
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Syllable-developer mailing list
> Syl...@li...
> https://lists.sourceforge.net/lists/listinfo/syllable-developer
>

Re: [Syllable-developer] Just a few diffs (Chipset)

[martin t. <tr...@Sa...>]

-------- Original Message --------
From: Kristian Van Der Vliet <va...@li...>
Apparently from: syl...@li...
To: syl...@li...
Subject: Re: [Syllable-developer] Just a few diffs (Chipset)
Date: Sun, 14 Sep 2008 22:52:28 +0100

> On Sun, 2008-09-14 at 23:16 +0200, Flemming wrote:
> > >On a side note, what's the common chipset vendors used by all of the  
> > >users/developers on this list.  I'd like for everyone to response  
> > >either on this list or email me directly. I can't use AltME at the  
> > >moment, so don't respond to this query there.
> > 
> > SiS on my primary, and Intel (I think) on the Eee.
> 
> Er, lets see. Mostly Intel ranging from i845 to x1300, then a Via KT400
> and one nVidia nForce board that currently doesn't boot.


Nforce 2 at the moment but thats going to be upgraded to a p35 or p45 chipset soon.

Intel chipset on an old x30 ibm thinkpad.

VIA on a test machine 

Martin N

Re: [Syllable-developer] Just a few diffs (Chipset)

[Kristian V. D. V. <va...@li...>]

On Sun, 2008-09-14 at 23:16 +0200, Flemming wrote:
> >On a side note, what's the common chipset vendors used by all of the  
> >users/developers on this list.  I'd like for everyone to response  
> >either on this list or email me directly. I can't use AltME at the  
> >moment, so don't respond to this query there.
> 
> SiS on my primary, and Intel (I think) on the Eee.

Er, lets see. Mostly Intel ranging from i845 to x1300, then a Via KT400
and one nVidia nForce board that currently doesn't boot.

-- 
Vanders
http://www.syllable.org

Re: [Syllable-developer] Just a few diffs (Chipset)

[Flemming <fle...@sy...>]

>On a side note, what's the common chipset vendors used by all of the  
>users/developers on this list.  I'd like for everyone to response  
>either on this list or email me directly. I can't use AltME at the  
>moment, so don't respond to this query there.

SiS on my primary, and Intel (I think) on the Eee.

Re: [Syllable-developer] Just a few diffs

[Kaj de V. <ka...@sy...>]

Still the same, as far as I can see.

Kaj


Dee Sharpe schreef:
> Is it the same crash as before? Any new behaviors?
>
> Dee Sharpe
>
> Sent from my iPhone
>
> On Sep 14, 2008, at 10:07 AM, Kaj de Vos <ka...@sy...> wrote:
>
>   
>> The VIA AGP driver is still crashing the system boot. We're getting
>> close to release, though. The rest is mostly cleaning up.
>>
>> Kaj
>>
>>
>> Dee Sharpe schreef:
>>     
>>> Is this build close to a stable drop?  I'm in the middle of a move,  
>>> so
>>> I won't have internet via desktop for a few days. However, I'm still
>>> anxious to see if the same agp issues exist. I have a feeling that it
>>> was a build issue, since all it took was for me to rebuild them.
>>>
>>> On a side note, what's the common chipset vendors used by all of the
>>> users/developers on this list.  I'd like for everyone to response
>>> either on this list or email me directly. I can't use AltME at the
>>> moment, so don't respond to this query there.
>>>
>>> Dee Sharpe
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 14, 2008, at 8:21 AM, Kristian Van Der Vliet
>>> <va...@li...> wrote:
>>>
>>>
>>>       
>>>> On Thu, 2008-08-28 at 02:59 -0400, dem...@ne...
>>>> wrote:
>>>>
>>>>         
>>>>> Here are 2 agp header diffs, an agp busmanager diff, pci_vendor.h
>>>>> diff, and an atomic.h diff.  These are small diffs that add a few
>>>>> things.  Please patch their respective files.
>>>>>
>>>>>           
>>>> Sorry for taking so long, as I've been trying to get a working build
>>>> machine back up and running. I finally got a new development build  
>>>> out
>>>> yesterday, so I've now checked your patches in (& the kdebug.h  
>>>> patch)
>>>>
>>>> -- 
>>>> Vanders
>>>> http://www.syllable.org
>>>>
>>>>
>>>>
>>>> ---
>>>> --- 
>>>> -------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>> the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Syllable-developer mailing list
>>>> Syl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/syllable-developer
>>>>
>>>>         
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win  
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in  
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Syllable-developer mailing list
>>> Syl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/syllable-developer
>>>
>>>
>>>       
>> --- 
>> ----------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Syllable-developer mailing list
>> Syl...@li...
>> https://lists.sourceforge.net/lists/listinfo/syllable-developer
>>     
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Syllable-developer mailing list
> Syl...@li...
> https://lists.sourceforge.net/lists/listinfo/syllable-developer
>
>