q-lang-users Mailing List for Q - Equational Programming Language (Page 27)
Brought to you by:
agraef
Menu
▾
▴
q-lang-users — general discussion, questions, suggestions, etc.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(3) |
Feb
(27) |
Mar
|
Apr
(4) |
May
(11) |
Jun
(5) |
Jul
(5) |
Aug
(6) |
Sep
(15) |
Oct
(28) |
Nov
(8) |
Dec
|
| 2005 |
Jan
(9) |
Feb
(5) |
Mar
(10) |
Apr
(43) |
May
(8) |
Jun
(31) |
Jul
(45) |
Aug
(17) |
Sep
(8) |
Oct
(30) |
Nov
(2) |
Dec
(6) |
| 2006 |
Jan
(4) |
Feb
(20) |
Mar
(1) |
Apr
|
May
(92) |
Jun
(179) |
Jul
(26) |
Aug
(65) |
Sep
(36) |
Oct
(38) |
Nov
(44) |
Dec
(68) |
| 2007 |
Jan
(11) |
Feb
(25) |
Mar
(37) |
Apr
(7) |
May
(83) |
Jun
(77) |
Jul
(44) |
Aug
(4) |
Sep
(28) |
Oct
(53) |
Nov
(12) |
Dec
(21) |
| 2008 |
Jan
(66) |
Feb
(45) |
Mar
(30) |
Apr
(50) |
May
(9) |
Jun
(18) |
Jul
(11) |
Aug
(6) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Albert G. <Dr....@t-...> - 2006-12-19 23:23:53
|
Hi everybody. Ok, so Q 7.6 is essentially ready. The RC2 tarball now up on sf.net will most probably be the final one. Meanwhile I've also uploaded the Windows binaries. Linux RPMs will follow soon, I'm just waiting for Andrew to confirm that the new release now compiles cleanly on OSX. All this can be found in the "rcs" section right now, see http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958&release_id=472275 Does anyone else here have a Zaurus PDA? I've also created a new feed for OpenZaurus users at: http://q-lang.sourceforge.net/feed/OpenZaurus There you can also find a README file which explains how to get Q 7.6 up and running on the Z. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-12-19 22:57:56
|
Albert Graef wrote: > Andrew Berg wrote: >> It looks to me like "regex_next" is doing all the work, and if asked to predict, I would guess that it is tail recursive. > > No, the current version is not. And yes, I guess you're right with your > suspicion that regex_next is the culprit here. It shouldn't be a big > deal to rewrite regex_next so that it's tail-recursive, though. Ok, here is a tail-recursive implementation of regex. Just put this at the beginning of your script and fetch_history "AA" goes through without a hitch (takes a while, though). (I might also use this definition in the next version of clib, but not right now as I haven't tested it thoroughly yet and I don't want to hold back the 7.6 release any longer.) special regex ~OPTS ~REGEX ~S EXPR, regex_next ~Xs EXPR; special check ~P X Y; regex OPTS:String REGEX:String S:String EXPR = check (regmatch OPTS REGEX S) (reverse (regex_next [EXPR] EXPR)) []; regex_next Xs EXPR = check regnext (regex_next [EXPR|Xs] EXPR) Xs; check P:Bool X Y = X if P; = Y otherwise; check P X Y = P otherwise; Also note that using regex to just split a string at a given delimiter is really overkill. There's the split function which does this much faster (clib provides a C implementation of that function). To use this, just s/regsplit "g"/split/ in your script and fetch_history "AA" runs much faster. HTH, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-12-19 21:46:55
|
Andrew Berg wrote: > My OS X version is 10.4.8 (as noted at the very top of that first email, but easily overlookable). Oops, sorry, I missed that. So 10.4.8 is as new as it gets. Good. I added your patch and uploaded a new RC2: http://downloads.sourceforge.net/q-lang/q-7.6rc2.tar.gz It would be nice if you could check once more whether this now compiles ok. If it's ok then I can release 7.6. > I guess I should try to figure out my ADC (Apple Developer Connection) password and see if this is a reported bug. Hmm, it might have something to do with the disabling of the _POSIX_C_SOURCE option. Maybe that also has an influence on the definition of setprgp. Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Andrew B. <an...@vo...> - 2006-12-19 21:16:17
|
>Andrew Berg wrote: >> I get an error compiling clib.c: >> > >The iconv warnings are harmless. The real culprit is setpgrp, see my >other post. > Yup. I didn't look closely enough to differentiate between "warning" = and "error" as I was a bit under the gun. My OS X version is 10.4.8 (as = noted at the very top of that first email, but easily overlookable). I guess I should try to figure out my ADC (Apple Developer Connection) = password and see if this is a reported bug. -andrew |
|
From: Albert G. <Dr....@t-...> - 2006-12-19 18:15:46
|
Andrew Berg wrote: > It looks to me like "regex_next" is doing all the work, and if asked to predict, I would guess that it is tail recursive. No, the current version is not. And yes, I guess you're right with your suspicion that regex_next is the culprit here. It shouldn't be a big deal to rewrite regex_next so that it's tail-recursive, though. > (H contains 1/2 MB of text in 11286 lines.) I'm not sure exactly what to do from here. Could you please send me the text file (zipped up, in pm) that you used for testing? Then I'll see what I can do about it. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-12-19 13:38:54
|
Andrew Berg wrote: > I get an error compiling clib.c: > > clib.c: In function 'ictowcs': > clib.c:698: warning: passing argument 2 of 'libiconv' from > incompatible pointer type > clib.c: In function 'icfromwcs': > clib.c:719: warning: passing argument 2 of 'libiconv' from > incompatible pointer type > clib.c: In function '__F__clib_setpgrp': > clib.c:7141: error: too many arguments to function 'setpgrp' > clib.c: In function '__F__clib_iconv': > clib.c:9187: warning: passing argument 2 of 'libiconv' from > incompatible pointer type > > Sadly, I don't have time to look into it tonight. I have some hope > that it is just that my libiconv being out of date or something. The iconv warnings are harmless. The real culprit is setpgrp, see my other post. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-12-19 13:13:07
|
Andrew Berg wrote: > Ok, from the man page: > int > setpgrp(pid_t pid, pid_t pgrp); > ...which would support your claims. On the other hand, looking at > 'unistd.h', I find: > > -------------------------------- > 448 #if __DARWIN_UNIX03 > 449 pid_t setpgrp(void) __DARWIN_ALIAS(setpgrp); > 450 #else /* !__DARWIN_UNIX03 */ > 451 int setpgrp(pid_t pid, pid_t pgrp); /* obsoleted > by setpgid() */ > 452 #endif /* __DARWIN_UNIX03 */ > -------------------------------- Hmm, so it seems that you actually have a setprgp which takes no parameters, in spite of what the manpage says. This is also confirmed by the compile error you reported in your other post. So which OSX version do you have? I need to know to be able to decide what to do about this... It should be something like 10.x.y, x=?, y=? Should be written on your OSX CDROM that you got with your Mac, I guess. Or maybe uname -a will tell you the version. Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Andrew B. <and...@ya...> - 2006-12-19 07:35:14
|
I get an error compiling clib.c: clib.c: In function 'ictowcs': clib.c:698: warning: passing argument 2 of 'libiconv' from incompatible pointer type clib.c: In function 'icfromwcs': clib.c:719: warning: passing argument 2 of 'libiconv' from incompatible pointer type clib.c: In function '__F__clib_setpgrp': clib.c:7141: error: too many arguments to function 'setpgrp' clib.c: In function '__F__clib_iconv': clib.c:9187: warning: passing argument 2 of 'libiconv' from incompatible pointer type Sadly, I don't have time to look into it tonight. I have some hope that it is just that my libiconv being out of date or something. -andrew On 18 Dec 2006, at 13:36, Albert Graef wrote: > Hi, > > I just uploaded a snapshot of the forthcoming Q 7.6 to sf.net. You can > grab it here: http://downloads.sourceforge.net/q-lang/q-7.6rc1.tar.gz > > This is a bugfix release. The ChangeLog is here: > http://sourceforge.net/project/shownotes.php? > release_id=472275&group_id=96881 > > As always, reports about compilation quirks on different platforms are > most welcome. :) Andrew, could you please check whether this > version now > compiles cleanly on OSX? > > I've already built the binary packages for Linux and Windows, and I'm > currently building packages for OpenZaurus. So if I don't have to > do any > last-minute fixes then I can upload the final version tomorrow. > > Cheers, > Albert > > -- > Dr. Albert Gr"af > Dept. of Music-Informatics, University of Mainz, Germany > Email: Dr....@t-..., ag...@mu... > WWW: http://www.musikinformatik.uni-mainz.de/ag > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > q-lang-users mailing list > q-l...@li... > https://lists.sourceforge.net/lists/listinfo/q-lang-users |
|
From: Andrew B. <and...@ya...> - 2006-12-19 07:14:16
|
I'm currently running Mac OS X Version 10.4.8
Ok, from the man page:
--------------------------------
SETPGID(2) BSD System Calls Manual
SETPGID(2)
NAME
setpgid, setpgrp -- set process group
SYNOPSIS
#include <unistd.h>
int
setpgid(pid_t pid, pid_t pgrp);
int
setpgrp(pid_t pid, pid_t pgrp);
DESCRIPTION
Setpgid() sets the process group of the specified process pid
to the
specified pgrp. If pid is zero, then the call applies to the
current
process.
--------------------------------
...which would support your claims. On the other hand, looking at
'unistd.h', I find:
--------------------------------
448 #if __DARWIN_UNIX03
449 pid_t setpgrp(void) __DARWIN_ALIAS(setpgrp);
450 #else /* !__DARWIN_UNIX03 */
451 int setpgrp(pid_t pid, pid_t pgrp); /* obsoleted
by setpgid() */
452 #endif /* __DARWIN_UNIX03 */
--------------------------------
...at which point I quit following. It appears that __DARWIN_UNIX03
is being set in 'sys/cdefs.h', but I wouldn't bet money on that. The
relavant lines:
--------------------------------
211 /*
212 * The __DARWIN_ALIAS macros is used to do symbol renaming,
213 * they allow old code to use the old symbol thus maintiang
binary
214 * compatability while new code can use a new improved
version of the
215 * same function.
216 *
217 * By default newly complied code will actually get the same
symbols
218 * that the old code did. Defining any of _APPLE_C_SOURCE,
_XOPEN_SOURCE,
219 * or _POSIX_C_SOURCE will give you the new symbols.
Defining _XOPEN_SOURCE
220 * or _POSIX_C_SOURCE also restricts the avilable symbols to
a subset of
221 * Apple's APIs.
222 *
223 * __DARWIN_ALIAS is used by itself if the function
signature has not
224 * changed, it is used along with a #ifdef check for
__DARWIN_UNIX03
225 * if the signature has changed. Because the __LP64__
enviroment
226 * only supports UNIX03 sementics it causes __DARWIN_UNIX03
to be
227 * defined, but causes __DARWIN_ALIAS to do no symbol mangling.
228 */
229
230 #if !defined(__DARWIN_UNIX03)
231 #if defined(_APPLE_C_SOURCE) || defined(_XOPEN_SOURCE) ||
defined(_POSIX_C_SOURCE) || defined(__LP64__)
232 #if defined(_NONSTD_SOURCE)
233 #error "Can't define both _NONSTD_SOURCE and any of
_APPLE_C_SOURCE, _XOPEN_SOURCE, _POSIX_C_SOURCE, or __LP64__"
234 #endif /* _NONSTD_SOURCE */
235 #define __DARWIN_UNIX03 1
236 #elif defined(_NONSTD_SOURCE)
237 #define __DARWIN_UNIX03 0
238 #else /* default */
239 #define __DARWIN_UNIX03 0
240 #endif /* _APPLE_C_SOURCE || _XOPEN_SOURCE ||
_POSIX_C_SOURCE || __LP64__ */
241 #endif /* !__DARWIN_UNIX03 */
242
243 #if __DARWIN_UNIX03 && !defined(__LP64__)
244 #define __DARWIN_ALIAS(sym) __asm("_" __STRING(sym)
"$UNIX2003")
245 #else
246 #define __DARWIN_ALIAS(sym)
247 #endif
--------------------------------
Anyhow, I have no idea if this helps at all. If you remember my
silly little post from about a month ago: "Years ago, when I was
young and idealistic I would worry about how stuff was "supposed" to
work. Now I just look
in the header files and try to figure out what _will_ work."
-andrew
On 16 Dec 2006, at 18:42, Albert Graef wrote:
> Andrew Berg wrote:
>> +#ifdef __APPLE__
>> +/* Need to undef _POSIX_C_SOURCE to get AF_LOCAL defined. */
>> +#undef _POSIX_C_SOURCE
>> +#endif
>
> Ok, this is in cvs now.
>
>> +/* This one actually does not get it wrong... */
>> +#if defined(__APPLE__)
>> +#define SETPGRP_VOID
>> +#endif
>
> Are you sure about this? Last time I checked, and according to the
> web-based documentation, setpgrp still expects two pid_t
> parameters, see
> http://www.hmug.org/man/2/setpgrp.php. That would imply that #undef
> SETPGRP_VOID is the right setting. Could you please verify that
> with the
> setpgrp man page on your system? And, btw, which OSX version do you
> have
> (Jaguar? Tiger?)?
>
> Thanks,
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email: Dr....@t-..., ag...@mu...
> WWW: http://www.musikinformatik.uni-mainz.de/ag
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
|
|
From: Andrew B. <an...@vo...> - 2006-12-19 06:09:42
|
Ok, I found the stack overflow that's been giving me troubles. It is in =
clib.q, in the "regex" function. Apparently this regex implementation =
breaks down when being used to split an 11k line file.
It looks to me like "regex_next" is doing all the work, and if asked to =
predict, I would guess that it is tail recursive. I thought that my =
"EXPR" might be causing the trouble, so I tried:
=3D=3D> regex "g" "\n" H 1
! Stack overflow
>>> regex "g" "\n" H 1
^
(H contains 1/2 MB of text in 11286 lines.) I'm not sure exactly what =
to do from here.
-andrew
-----Original Message-----
From: Albert Graef
Andrew Berg wrote:
> =3D=3D> run fin.q
>=20
> =3D=3D> fetch_history "AA"
>=20
> C:\Documents and Settings\andrewb\Desktop\fin>
> ---------------------------------------------
>=20
> Maybe this example does not make it so obvious, but it
> appears to me that I am the victim of a silent
> failure.
Yes, I can confirm this, it also happens on Linux. It's a C stack
overflow in the interpreter's internal eval routine. We've discussed
this before, see:
=
http://sourceforge.net/mailarchive/forum.php?thread_id=3D30658130&forum_i=
d=3D36790
|
|
From: Albert G. <Dr....@t-...> - 2006-12-18 21:31:54
|
Hi, I just uploaded a snapshot of the forthcoming Q 7.6 to sf.net. You can grab it here: http://downloads.sourceforge.net/q-lang/q-7.6rc1.tar.gz This is a bugfix release. The ChangeLog is here: http://sourceforge.net/project/shownotes.php?release_id=472275&group_id=96881 As always, reports about compilation quirks on different platforms are most welcome. :) Andrew, could you please check whether this version now compiles cleanly on OSX? I've already built the binary packages for Linux and Windows, and I'm currently building packages for OpenZaurus. So if I don't have to do any last-minute fixes then I can upload the final version tomorrow. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2006-12-18 21:06:15
|
Albert Graef scripsit: > Yes, I see, that is also the solution that I had in mind. It's on my > TODO list for Q 7.7. Thanks for clearing that up. Chicken, however, loses only efficiency if the stack is too small; on stack overflow, it evicts live data to the heap, trampolines back to the beginning with longjmp(), and continues. Q may need more than 128K of C stack. -- John Cowan co...@cc... http://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable |
|
From: Albert G. <Dr....@t-...> - 2006-12-18 21:00:07
|
John Cowan wrote: > Yes. Chicken uses a default stack size of 128K. You can change this > by rebuilding it, or with a command-line argument. It simply compares > the address of a local variable near the current top of stack with one > known to be at the bottom of the stack, and takes action if the pointer > difference is too large. Yes, I see, that is also the solution that I had in mind. It's on my TODO list for Q 7.7. Thanks for clearing that up. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2006-12-18 20:34:59
|
Albert Graef scripsit: > (NB: John, I seem to recall that you asked a fellow chicken developer > for the code they use to detect and handle C stack overflows. Did you > ever get a reply?) Yes. Chicken uses a default stack size of 128K. You can change this by rebuilding it, or with a command-line argument. It simply compares the address of a local variable near the current top of stack with one known to be at the bottom of the stack, and takes action if the pointer difference is too large. -- John Cowan co...@cc... http://ccil.org/~cowan If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli |
|
From: Albert G. <Dr....@t-...> - 2006-12-18 20:12:46
|
Albert Graef wrote: > [...] Apparently sf.net's mailing lists are broken > again. The archive looks like a big mess, with broken formatting of the > messages, a defunct thread display, and lots of spam I don't know how to > get rid of. Oh well. :( Well, just as I was about to file a support request I took another look at the ml archive and, lo and behold, it's fixed! Looks like the sf.net people read my mind. ;-) The spam is a PITA though, when looking at the archive. Does anyone know whether it's possible on sf.net to delete posts from a mail archive? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-12-18 20:04:24
|
Andrew Berg wrote: > ==> run fin.q > > ==> fetch_history "AA" > > C:\Documents and Settings\andrewb\Desktop\fin> > --------------------------------------------- > > Maybe this example does not make it so obvious, but it > appears to me that I am the victim of a silent > failure. Yes, I can confirm this, it also happens on Linux. It's a C stack overflow in the interpreter's internal eval routine. We've discussed this before, see: http://sourceforge.net/mailarchive/forum.php?thread_id=30658130&forum_id=36790 But there's not much I can do about it right now. It should be possible to handle these errors in a more friendly way (I still have this on the TODO list for the 7.x series), but that still won't make the real problem go away, which almost certainly is a space leak in your script (see below). (NB: John, I seem to recall that you asked a fellow chicken developer for the code they use to detect and handle C stack overflows. Did you ever get a reply?) Ok, to verify this stack overflow condition you can set Q's activation stack size to a small value, then the interpreter will give you a "soft" stack overflow error instead. E.g.: ==> stacksize 1024 ==> fetch_history "AA" ! Stack overflow >>> fetch_history "AA" ^ Now how to work around this? It looks like you have a space leak in your script, i.e., some huge unevaluated (special) arguments are getting passed around and then later evaluated. That could be the if-then in the definition of cache_get; try replacing that with a conditional equation. If that doesn't help, fire up Q's debugger to see exactly where those big expressions build up and try to rewrite this code. If you figure this out, please let me know. I might also take a closer look myself, when I have the time, because your program could be an interesting example for the "Gotchas" chapter of my Q book: space leaks in Q and how to avoid them. ;-) Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-12-18 18:21:34
|
/me wrote: > Hmm sorry, but I still can't find that message with the fixed fini.q Scratch that, I found it. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-12-18 13:21:07
|
Andrew Berg wrote: > Aah, I look forward to getting to Section B of the manual, then. So far I'm up to chapter 12. I resent the bug report...and I see the message reflected by the list this time, so perhaps you'll actually get it this time. Hmm sorry, but I still can't find that message with the fixed fini.q script. Could you maybe resend it to my pm (Dr.Graef..., see below)? I'm currently about to finish the next bugfix release, so it would be the last opportunity to get this bug fixed in 7.6 as well. Sorry for the hassle. Apparently sf.net's mailing lists are broken again. The archive looks like a big mess, with broken formatting of the messages, a defunct thread display, and lots of spam I don't know how to get rid of. Oh well. :( Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
q-lang-users様 お世話になっております。 私どもは自由恋愛促進を目的に、条件にあったセフレのペアリング、 大人の恋愛のきっかけをサポート中です。 貴方様を招待します、【No.20024】瑞穂様の紹介スペースは ご覧頂いているでしょうか。 今回は20-25歳カテゴリーにて同地区エリアの方だけの対象で、 優先的にご依頼人から貴方様へのご招待となりました。 瑞穂様の希望としまして、自己紹介やメールでの連絡をした後に、 お近くのカフェで待ち合わせを希望しています。 スケジュールのほうはいかがでしょうか。 お互いの休日や夜の予定などは、お互いでご相談頂けますか。 こちらがあらためまして紹介カードです。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 【No.20024】瑞穂様から ┌──┐ │＼／│ ご招待カードを開封する http://takumi.vicp.cc/acfree/20024 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
q-lang-users様 お世話になっております。 私どもは自由恋愛促進を目的に、条件にあったセフレのペアリング、 大人の恋愛のきっかけをサポート中です。 貴方様を招待します、【No.20024】瑞穂様の紹介スペースは ご覧頂いているでしょうか。 今回は20-25歳カテゴリーにて同地区エリアの方だけの対象で、 優先的にご依頼人から貴方様へのご招待となりました。 瑞穂様の希望としまして、自己紹介やメールでの連絡をした後に、 お近くのカフェで待ち合わせを希望しています。 スケジュールのほうはいかがでしょうか。 お互いの休日や夜の予定などは、お互いでご相談頂けますか。 こちらがあらためまして紹介カードです。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 【No.20024】瑞穂様から ┌──┐ │＼／│ ご招待カードを開封する http://takumi.vicp.cc/acfree/20024 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
From: Albert G. <Dr....@t-...> - 2006-12-17 02:38:13
|
Andrew Berg wrote: > +#ifdef __APPLE__ > +/* Need to undef _POSIX_C_SOURCE to get AF_LOCAL defined. */ > +#undef _POSIX_C_SOURCE > +#endif Ok, this is in cvs now. > +/* This one actually does not get it wrong... */ > +#if defined(__APPLE__) > +#define SETPGRP_VOID > +#endif Are you sure about this? Last time I checked, and according to the web-based documentation, setpgrp still expects two pid_t parameters, see http://www.hmug.org/man/2/setpgrp.php. That would imply that #undef SETPGRP_VOID is the right setting. Could you please verify that with the setpgrp man page on your system? And, btw, which OSX version do you have (Jaguar? Tiger?)? Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: <pan...@ya...> - 2006-12-14 19:04:53
|
q-lang-users様 >>> 招待カード セフレ促進、自由恋愛コミュニティから大人のつながる 招待カードをお届けしました。 無料掲示板での近所検索により貴方様が 該当しましてご依頼人からのご招待となりました。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 【No.20024】瑞穂様から ┌──┐ │＼／│ ご招待カードを開封する http://takumi.vicp.cc/acfree/20024 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
From: <pan...@ya...> - 2006-12-14 18:25:33
|
q-lang-users様 >>> 招待カード セフレ促進、自由恋愛コミュニティから大人のつながる 招待カードをお届けしました。 無料掲示板での近所検索により貴方様が 該当しましてご依頼人からのご招待となりました。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 【No.20024】瑞穂様から ┌──┐ │＼／│ ご招待カードを開封する http://takumi.vicp.cc/acfree/20024 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
From: Andrew B. <and...@ya...> - 2006-12-05 06:25:08
|
On 3 Dec 2006, at 06:39, Marco Maggesi wrote: > Being totally illiterate on all this kind of stuff, i can't say if > this is the correct behavior or not. Don't worry about it. Years ago, when I was young and idealistic I would worry about how stuff was "supposed" to work. Now I just look in the header files and try to figure out what _will_ work. :) I guess I've gotten jaded. -andrew |
|
From: Marco M. <ma...@ma...> - 2006-12-03 14:39:56
|
On Dec 3, 2006, at 2:16 AM, Albert Graef wrote: > That seems to be an issue with Apple's system headers. A proper fix =20= > can > be found in Andrew Berg's post (I'll include that in the next =20 > release): > http://sourceforge.net/mailarchive/forum.php?=20 > thread_id=3D31075130&forum_id=3D36790 It works! > What's bizarre is that on OSX (at least on recent versions, I don't > remember seeing this the last time I compiled Q on OSX) you apparently > have to *#undef* _POSIX_C_SOURCE to get AF_LOCAL defined. I always > thought that AF_LOCAL was mandated by POSIX (rather than AF_UNIX)? In fact, in sys/cdefs.h there is the following code: #ifndef _POSIX_C_SOURCE #define AF_LOCAL AF_UNIX /* backward compatibility */ #endif /* !_POSIX_C_SOURCE */ Being totally illiterate on all this kind of stuff, i can't say if =20 this is the correct behavior or not. Thank you. Marco Maggesi Universit=E0 degli Studi di Firenze http://www.math.unifi.it/~maggesi/ |
38 messages has been excluded from this view by a project administrator.
