r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

GrahamC
20-Feb-2012
[2870]
lol
Geomol
20-Feb-2012
[2871x2]
Exactly! :)
Or ... if the language makes you do anything, like e.g. C, and what 
it does, it does well, then it doesn't matter, if it's closed source 
or not.
Pekr
20-Feb-2012
[2873]
Geomol's right. R2 can be extended via DLLs, and R3 via extensions. 
But that might not solve all usage cases or needed fixes in Core 
...
Geomol
20-Feb-2012
[2874]
I don't care, if my C compiler is closed source or not, because it 
just works. I also shouldn't care, if my COBOL compiler and interpreter 
is closed source or not, but I actually do, because the company behind 
can't figure out to make graphical tables (called GRIDs) the correct 
way, so my COBOL programs doesn't work as intended, and I have to 
create work-arounds. Years ago, I didn't care, if REBOL was closed 
source or open, but later I did, because I couldn't finish projects, 
I made with it.


Any future language, I would use, I don't care if it's closed or 
open, if it delivers, what it promices. If it doesn't, it's another 
case.
Steeve
20-Feb-2012
[2875x2]
The problem is that what you think is the correct way to do things 
may be not
Others have needs you don't care in the end.
Geomol
20-Feb-2012
[2877]
Ah, I have enough programming experience to figure out, if something 
is doable the 'right' way or not.
Steeve
20-Feb-2012
[2878]
Lol, Are you 20 or what ?
Geomol
20-Feb-2012
[2879x2]
:) nah
A good language is also easy to expand and integrate with other technologies. 
For some projects, it may be a good idea to have the language as 
a dynamic linked library.
Steeve
20-Feb-2012
[2881x2]
We all do mistakes even after years and years of practices
We all do mistakes even after years and years of practices
Geomol
20-Feb-2012
[2883x2]
sure
But that doesn't exclude, that if I use some time and think about 
some problem, I can figure out, if it's doable in some language the 
'right' way.
Steeve
20-Feb-2012
[2885x2]
Geomol, I already know that you made some technical choices in World 
that I would not have done because I think (maybe I'm wrong) I know 
better ways to do faster VM.

So, to my mind,you already failed in the task to deliver a promising 
clone.

Just to say that your 'needs' , expectations and technical skills 
are probably not the best in each room.
;-)
I mean, even Carl failed in that matter. Everyone do shitty design 
choices occasionally. It's why it's better to have friendly eyes 
behind our shoulder.
Ladislav
20-Feb-2012
[2887]
That's the problem with closed source languages

 - there is nothing like "closed source language". Only an interpreter/compiler 
 may be closed source.
Gregg
20-Feb-2012
[2888]
Lad +1


The REOL Syntax project is very important in this regard, and documenting 
the differences between the clones. Being the fastest VM my not be 
John's goal, if it means other tradeoffs.
Ladislav
20-Feb-2012
[2889]
Well, sure, the speed may not be the most important property.
Geomol
21-Feb-2012
[2890x2]
Copying a cyclic block:

>> blk: [a b c]
== [a b c]
>> insert/only blk blk
== [a b c]
>> blk
== [[...] a b c]
>> copy blk
== [[[...] a b c] a b c]

That's not correct, right?
Ah, it is. I just realized, when I wrote it. :)
Pekr
21-Feb-2012
[2892]
One question to library wrapping. I have a function, which should 
return a bool from C level, according to if the communication card 
is open, or not. When I am able to open the card, it returns 1 (mapped 
to R2 integer!), if not, it returns  30605312 - does that integer 
make any sence? I mean, does it e.g. translate to some C level slot, 
overflow, or -1 value? Just curious ...
Geomol
21-Feb-2012
[2893]
w> to binary! 30605312 
== #{0000000001D30000}

Maybe you read too many bits?
Pekr
21-Feb-2012
[2894]
I can't influence it, it is just result from the mapped function 
 C level code bool (dunno how it is defined) to R2's integer! value. 
Was just curious ....
Cyphre
21-Feb-2012
[2895]
Pekr, bool in C is usually of char type so you should try to set 
the returned value in your routine! spec to char.
Pekr
21-Feb-2012
[2896]
Cyphre: thanks, will try that ...
Oldes
21-Feb-2012
[2897]
Isn't it usually integer? It's must be defined somewhere btw.
Endo
22-Feb-2012
[2898]
In win.h include file in LCC compiler;
typedef int BOOL;
typedef unsigned char BOOLEAN;
Andreas
22-Feb-2012
[2899x3]
BOOL != bool.
bool is in C since C99, and it's, in fact, *drumroll* a typedef/#define 
for _Bool
(before C99, there's simply no standard boolean type available in 
C)
Endo
22-Feb-2012
[2902]
Yep, WG14/N869 January 18, 1999 Page 257
#define bool _Bool

There are some other definitions in different include files:

typedef  enum _BoolValue {True=1, False=0, BoolValue_Max=2147483647L 
} BoolValue;
typedef int bool;  //lowercase
typedef unsigned char boolean;

typedef enum { false, true } bool;  // this is for Borland C I guess
Ladislav
22-Feb-2012
[2903]
BOOL != bool

 - this is strange, I never found any note mentioning other datatype 
 than int for bool. While Pekr may be experiencing bool to be defined 
 as something smaller, all the documentation I found mentions it should 
 be int.
Andreas
22-Feb-2012
[2904x4]
The C standard is (as always) very vague and doesn't specify a particular 
storage size. I think it just defines that _Bool must be able to 
hold 0 and 1.
So when encountering a "bool", one really has to ask what kind of 
bool that is. More often than not, it won't be a C99 _Bool and will 
actually be int-sized.
If it is a C99 _Bool, it will typically be char-sized, though.
And I think Pekr really has a different case, because he's trying 
to use a C++ lib. C++ really has a bool, and I think it's char-sized 
(but I don't know whether that's impl-specific in C++ or defined 
in the C++ standard).
Ladislav
23-Feb-2012
[2908x3]
If it is a C99 _Bool, it will typically be char-sized, though.
 - hmm, I found explicitly stated that it should be int
The same for C++
I guess that other sizes are atypical and not exactly respecting 
the standard
Endo
23-Feb-2012
[2911]
when it is int it could be 64bit or 32bit.. depend on the compiler 
and the OS. 

Pekr: So may be the C library returns a 64bit integer: #{0000000001D30000} 
= #{00000000 - 01D30000}, the left part is 0 (=false) the second 
part is just a number from stack.. 
When you get in from R2 it become #{01D30000} = 30605312
Geomol
23-Feb-2012
[2912]
Or it's a 16 bit return, and the machine, it's from, is little endian, 
where World is big endian. Then it's the last 4 zeros in the result, 
that is the bool.
Endo
23-Feb-2012
[2913]
That could be too.
Cyphre
23-Feb-2012
[2914x2]
Lad, In C I tried:
#include <stdbool.h>
int main (int argc, const char * argv[]) {
    printf ("bool length %d\n", sizeof(bool));
    return 0;
}

The output was:
bool length 1

So it is usually char, at least in GNU C/C++
I haven't found any explicit type definition in the C99 though.
Andreas
23-Feb-2012
[2916x2]
{"If it is a C99 _Bool, it will typically be char-sized, though." 
-- hmm, I found explicitly stated that it should be int}

Where?
A slightly better test would be:

#include <stdio.h>

int main(int argc, char *argv[]) {printf("%ld\n", sizeof(_Bool)); 
return 0;}


And then compile that in C99 mode (i.e. -std=c99 for GCC; but C89/90 
compilers will bark on the unknown _Bool keyword anyway).


Better, because there exist(ed) a few stdbool.h versions prior to 
the final C99 standard which used e.g. unsigned integers for bools. 
Should be gone/fixed by now, but one never knows :)
Geomol
23-Feb-2012
[2918]
Under OS X using gcc, I get bool length 1 both with Cyphre and Andreas 
versions, and also with or without -std=c99 option.
Cyphre
23-Feb-2012
[2919:last]
Yes, I also used the C99 compiler flag. Andreas version is more correct 
test ofcourse.