[Chicken-users] repository cleanup
Hi! The toplevel eggs have now been moved into the release/2 directory. The post-commit code has been updated and seems to be running. I've seen that there have been some commits during the time of the reorganization. These commits have not resulted in egg updating, as the automatic post commit procedures were disabled during that period and later testing was necessary which reset the revision counter (yadda yadda... serves you right! why did you commit during this period?). I will follow all updates for the next days to fix problems. If you encounter any problems, missing uploads or so, please contact me or the chicken-hackers mailing list. Thanks for your patience. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] nondescript eggs
Hello! The following eggs have currently no .meta file and seem to be in a state of flux, or have not been implemented yet (but are registered in the repository: * binary-tree/ * dns/ * filesystem/ * gl-display-glx/ * gl-font/ * libapreq-mfd-parser/ * meroonet/ * methods/ * minioop/ * scoop/ * sockets/ * statvfs/ * swt/ * wxchicken/ These have been moved into the nondescript branch and can be accessed as usual (the permissions will be updated accordingly). Whoever is working on these, please consider moving them into the release/3 branch later, once you think they are ready for being made available. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two procedures looking for a good home
If redundancy were a reason for deleting egg functionality, we have about seven object systems to get rid of. ;-) Ah, but if you pick any two of those, they will have their differences! In this case, however, *absolutely* all usages of the new code are supported by the old one and it is *impossible* for a user to find any difference between them (other than the fact that orders' function is called cmp-key and the combinator's make-/key) no matter how hard they try. IMHO case that should be enough of a reason not to add the copy of the code in another egg with a different name. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two procedures looking for a good home
On Sun, Feb 24, 2008 at 1:16 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: If redundancy were a reason for deleting egg functionality, we have about seven object systems to get rid of. ;-) Ah, but if you pick any two of those, they will have their differences! In this case, however, *absolutely* all usages of the new code are supported by the old one and it is *impossible* for a user to find any difference between them (other than the fact that orders' function is called cmp-key and the combinator's make-/key) no matter how hard they try. No worries, I was just joking. :-) I agree, the redundancy is pointless. It's pointless, I say. I'd like to add a (sort/decorated lst cmp key) proc to your orders egg, that calculates the key values only once; this can be more efficient than (sort ... (cmp-key ...)) for cases where key generation is expensive. I think it fits in your egg; are you OK with that? (The name 'decorated' is an allusion to the 'decorate-sort-undecorate' idiom in Python, which this replicates; we can rename to something more clear.) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] C_truep( C_fixnump( w ))
hmmm it has nothing to do with the C_truep( C_fixnump( w )) test --
even if the else clause is empty it still crashes if the data are NOT
floats.
im sure this must be something stupid but i dont understand why it
crashes if its not float data
#
#include Csound.h
void cs_event (int type, int len, C_word lyst) {
// MYFLT buf[len];
printf(IN CS_EVENT, BEFORE LOOP LEN=%d\n, len);
int i=0;
for (; C_SCHEME_END_OF_LIST != lyst; lyst = C_u_i_cdr( lyst ) ) {
if (i==len) break;
C_word w = C_u_i_car( lyst );
if (C_truep( C_flonump( w ) )) {
printf(FLO: buf[%d]=%f\n, i++, (float)C_flonum_magnitude( w ));
}
else {
}
}
// ((GraceApp *)GraceApp::getInstance())-getCsoundPort()-
sendEvent(typ, len, buf);
}
#
(define (cs:i . args)
(if (not (null? args))
((foreign-lambda void cs_event int int scheme-object)
1
(length args)
args))
(values))
---
(cs:i 1.0 0.0 1.0 60.0 1000.0)
IN CS_EVENT, BEFORE LOOP LEN=5
FLO: buf[0]=1.00
FLO: buf[1]=0.00
FLO: buf[2]=1.00
FLO: buf[3]=60.00
FLO: buf[4]=1000.00
(cs:i 1 0 1 60 1000)
CRASH
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] C_truep( C_fixnump( w ))
On 2/24/08, Heinrich Taube [EMAIL PROTECTED] wrote:
im sure this must be something stupid but i dont understand why it
crashes if its not float data
C_word w = C_u_i_car( lyst );
if (C_truep( C_flonump( w ) )) {
Heinrich,
Try if (C_truep(C_blockp(w)) C_truep(C_flonump(w))) {...}
and see if it helps.
Since you're doing this completely in C, you don't really
have to convert to a scheme boolean either:
if (!C_immediatep(w) C_block_header(x) == C_FLONUM_TAG) { ... }
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two procedures looking for a good home
No worries, I was just joking. :-) I agree, the redundancy is pointless. It's pointless, I say. Ahh, hahahahah, I thought you were serious. Sowwy. I'd like to add a (sort/decorated lst cmp key) proc to your orders egg, that calculates the key values only once; this can be more efficient than (sort ... (cmp-key ...)) for cases where key generation is expensive. I think it fits in your egg; are you OK with that? You are still joking here, right? (See the sort-key-cache function in said egg.) ;-) Heheh. Alejo, feeling very redundant with Graham today. :-) http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two procedures looking for a good home
On Sun, Feb 24, 2008 at 1:55 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: I'd like to add a (sort/decorated lst cmp key) proc to your orders egg, that calculates the key values only once; this can be more efficient than (sort ... (cmp-key ...)) for cases where key generation is expensive. I think it fits in your egg; are you OK with that? You are still joking here, right? (See the sort-key-cache function in said egg.) ;-) D'oh, no I wasn't joking that time, I just hadn't read the whole egg properly. Funny. :-) Alejo, feeling very redundant with Graham today. :-) Heh. I am fighting a cold today; I didn't think it was impairing my judgment, but I think I was wrong... Best wishes, Graham http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] nondescript eggs
Guilty. I've committed my statvfs and filesystem eggs. Whatever svn-fu I may have once had is rusty. Can I just svn mv them into releases/3? Not sure I even have permissions for that... WHAT DO I DO NOW?!?? :-) (sorry for the dupe Felix, forgot to hit Reply All the first time) Felix Winkelmann wrote: Hello! The following eggs have currently no .meta file and seem to be in a state of flux, or have not been implemented yet (but are registered in the repository: * binary-tree/ * dns/ * filesystem/ * gl-display-glx/ * gl-font/ * libapreq-mfd-parser/ * meroonet/ * methods/ * minioop/ * scoop/ * sockets/ * statvfs/ * swt/ * wxchicken/ These have been moved into the nondescript branch and can be accessed as usual (the permissions will be updated accordingly). Whoever is working on these, please consider moving them into the release/3 branch later, once you think they are ready for being made available. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: Origin of 'chicken' scheme.
I went ahead and added the reply that felix gave in that older post to the FAQ page. http://chicken.wiki.br/faq#why-call-it-chicken ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] process-wait on pid returned by process
On Sun, Feb 24, 2008 at 7:10 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: Are these both close-output-port? (I guess this is a typo) Oops, yes, sorry, that was a typo in my example. Though, hmm, shouldn't Chicken throw an error in that case? Yeah, it should. closing both input and output ports will automatically do the process-wait for you. Ahh, OK. That looks good. What happens of the port doesn't get explicitly closed by me but instead gets garbage collected? Or should I always make sure to close them? Yes, you should make sure to close them. There are no finalizers on the port. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] nondescript eggs
On Mon, Feb 25, 2008 at 12:28 AM, Ozzi [EMAIL PROTECTED] wrote: Guilty. I've committed my statvfs and filesystem eggs. Whatever svn-fu I may have once had is rusty. Can I just svn mv them into releases/3? Not sure I even have permissions for that... WHAT DO I DO NOW?!?? :-) i'll move the stuff in the repo, mario will fix the permission. All is well. Thanks, Ozzi! cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
