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

World: r3wp

[Core] Discuss core issues

Steeve
9-Feb-2012
[2820]
Anyway O(n*n) is by far too dramatic ;-)
Pekr
10-Feb-2012
[2821x2]
where should I put DLLs, in order for REBOL to find them? I mean 
- I have one DLL, which is dependant on some other. Even if I put 
that DLL into the same directory, it complaints it can't find it. 
Win Vista here ...
or should I register them somehow using regsvr or something like 
that?
Oldes
10-Feb-2012
[2823]
I don't know how it's on Vista, but on W7 or XP you can place it 
anywhere... I today updated my old zlib script to do late initialisation, 
you can find it here: https://github.com/Oldes/rs/tree/88291b8c720e9026978a080ca40100c3f2fb780f/projects-dll/zlib/latest
Endo
10-Feb-2012
[2824]
Pekr: Registration (regsvr) is required only if they are ActiveX 
DLLs, but I think they are not because you cannot use ActiveX DLLs 
in REBOL.

Normally they should be somewhere in your PATH. Try to see what's 
happening with FileMon tool from Systeminternals.com.
Maxim
10-Feb-2012
[2825]
it also looks in the current-dir... but that path will depend of 
how you launched rebol.


use WHAT-DIR just before you try to load your dll  to know where 
the current-dir is at that time and put your dll there.


you can also add a path in the user or system path environment and 
place the dll there.
Pekr
11-Feb-2012
[2826x3]
I'll continue here for now, as /library is now a free part of Core, 
and DLL.SO is not web-public.
My observation is, that if there are one or more dependant DLLs, 
REBOL will load first one, but then the path is somehow not taking 
into account a present directory. Here's few pointns:

- you can't do: do %my-dir/my-dll-script.r
- nor you can do so after: change-dir 


But it works, when you launch REBOL from the directory where those 
DLLs are present.
There is several various paths in R2 structure, dunno if it is just 
weird R2 implementation, or OS level natural functionality ...
PeterWood
11-Feb-2012
[2829]
/library is not a free part of Core only View.
Geomol
17-Feb-2012
[2830x3]
If datatypes equals words, like word! = 'word!, then maybe the refinement 
in type?/word isn't needed? But what are the consequences? The next 
two examples would return the same:

>> find [integer! 42] integer!
== [42]
>> find [integer! 42] 'integer!
== [integer! 42]


I came to think of this, because I find myself writing things like 
the following all the time now:

	either find [block! paren!] type?/word value [ ...
and
	switch type?/word value [ ...


If datatypes equals words, only type? without the refinement would 
be needed.
I know, I today can write things like


 either find [#[datatype! block!] #[datatype! paren!]] type? value 
 [ ...


but I don't do that, because it has too much syntax for my taste, 
and therefore isn't very readable.
Maybe the question should be put the other way around: Are there 
cases (in real scripts), where it would be a problem, if datatypes 
equals words?
Ladislav
17-Feb-2012
[2833]
FYI - datatypes were never words, but they were examples of specific 
datatypes in R1
Geomol
17-Feb-2012
[2834x2]
refinement! is member of the any-word! typeset together with word!, 
set-word!, get-word! and lit-word!. My thoughts above lead to asking 
if also none! and logic! should be part of any-word! with datatype! 
too? Examples from R2:

>> /ref = 'ref
== true
>> find [/ref]Ê'ref
== none		; this is strange to me

Maybe all the next should succeed?

>> find [true] true
== none
>> find [none] none
== none
>> find [integer!] integer!
== none
It's funny, that the following succeed, but for another reason:

>> find [word!] word!
== [word!]
Andreas
17-Feb-2012
[2836x2]
none! and logic! are simply not word types, so it makes no sense 
to have them in the any-word! typeset. none/true/false being words 
conveniently pre-bound to values of the corresponding datatypes does 
not change that.
Note that we also have a literal syntax for none! and logic! values 
now, which makes all your finds succeed even without reducing:

>> find [#[true]] true
== [true]

Etc.
Geomol
17-Feb-2012
[2838x2]
Integers are not decimals, but they're both numbers, and we can check 
like:

>> 1 = 1.0
== true

Refinement are not words, but they're both any-words.


Why not let datatypes (and none and logic) be any-words just the 
same? If the benefit from doing so is big, then it could be a good 
idea.
w> /refinement = 'refinement
== true

The question is, if the following would lead to a disaster?

w> integer! = 'integer!
== true
Andreas
17-Feb-2012
[2840]
In any case, I wouldn't conflate that question with the question 
of #[true] = 'true.
Gregg
17-Feb-2012
[2841]
There is a big difference between having datatypes be word values, 
versus having them fall under the any-word pseudotype. The latter 
seems OK, but not the former. If I understand you, it would cause 
things like [datatype? integer!] to fail, because it would return 
word!. That is, we lose them as an identifiable datatype. I use them 
for reflective tools and dialects. While the change wouldn't make 
that impossible, I like them being first class citizens as they are 
today.
Geomol
17-Feb-2012
[2842x2]
No, let me clarify. I want integer! to represent a datatype, like 
1 represents an integer. So datatype? integer! should return true, 
and word? integer! should return false, just like decimal? 1 returns 
false.


I simple suggest equal? to return true, when comparing a datatype 
with a word of the same spelling. Like this is true:

>> equal? 1 1.0
== true
Technical speaking, it's an expanded coercion for the equal operator, 
=, (and so also for the equal? function).
Oldes
19-Feb-2012
[2844x4]
What is the best way how to simulate R3's map! in R2? It would be 
enough to have safe key-value pairs?
in R3:
>> b: make map! ["a" "b" "b" "c"]
== make map! [
    "a" "b"
    "b" "c"
]

>> select b "b"
== "c"

in R2 I know only:
>> all [tmp: select/skip b "b" 2 first tmp]
== "c"
I really would like to know, why the hell is the result with /skip 
refinement in block:/
It's really sad to know, that we cannot expect any improvements in 
a future:/
Ladislav
19-Feb-2012
[2848x2]
MAP is an associative (Key <-> Value) data "storage". In R2 a correspoding 
way would be to use the hash! datatype, however, if you want to discern 
keys from values you need to use a separate Keys hash! and a separate 
Values block, otherwise you end up having Keys and Values intermixed. 
Your way of using the /skip refinement and a block is slower, however 
it searches only in Keys as well due to the /skip 2 use. When not 
used, it would search in Values.
(hope it explains it a bit)
Oldes
19-Feb-2012
[2850x2]
I know the theory:/ To have separate hashes for key and values would 
be even more complicated. I would be fine if the select/skip would 
not return a block which is simply stupid... or correct me if there 
is any reason for that. It's sad we cannot have map! in R2.
In my case I will have just a few key-value pairs.. so the speed 
is not a problem, more important is to be safe that the key will 
not be mixed with values.
Ladislav
19-Feb-2012
[2852]
To have separate hashes for key and values would be even more complicated

 - that is wrong, there is no need to have two hashes, moreover, it 
 is not complicated, I wrote the corresponding software, and it is 
 easy
Oldes
19-Feb-2012
[2853]
If I could move time back a few years and I could vote, I would like 
Carl to enhance R2 a little bit instead of starting R3 which he probably 
never finish.
GrahamC
19-Feb-2012
[2854]
Didn't he "say" that he was going to spend some weekend time on it?
Ladislav
19-Feb-2012
[2855]
Oldes, why don't you:

- ask for the R2 Map! code or
- write your own

instead of writing that "if I could"?
Oldes
19-Feb-2012
[2856x3]
The question is when his weekend starts.. if his hour has so many 
minutes... but it would be nice to have his weekend using same hour 
type.
I have the code:

get-attribute: func[name /local tmp][all [tmp: select/skip attributes 
name 2 first tmp]]

but it's so UGLY.
And I will not ask.. I was asking so many times without any response 
that I gave up long time ago.
Ladislav
19-Feb-2012
[2859x3]
That is not complete in that it does not handle other operations 
than GET-ATTRIBUTE
I gave up even longer time ago offering my code :-p
...also, I am not sure, but maybe BrianH also offers his own version
Oldes
19-Feb-2012
[2862]
Hm.. the reason for the additional block with the /skip is thi sone:
>> b: ["a" "b" "c" "d"   "b" "c" "d" "e"] select/skip b "b" 4
== ["c" "d" "e"]
Endo
19-Feb-2012
[2863]
Oldes: I was just about to write this, I asked is this a bug a few 
months ago, but no, it returns a block when you select with /skip 
because you can select more-than-one value if your skip size is > 
2 , otherwise you cannot get the further values. You select block 
of values when use /skip.
Geomol
19-Feb-2012
[2864x2]
Maybe do somehing like:

>> keys: make hash! ["a" "b"]
== make hash! ["a" "b"]
>> values: ["b" "c"]
== ["b" "c"]
>> pick values index? find keys "a"
== "b"
>> pick values index? find keys "b"
== "c"

The
	pick values index? find keys
could be put in a nice function to call.
Or wrap it in a context:

map: context [
	keys: make hash! ["a" "b"]
	values: ["b" "c"]
	pick: func [value] [
		system/words/pick values index? find keys value
	]
]

>> map/pick "a"
== "b"
>> map/pick "b"
== "c"
Oldes
19-Feb-2012
[2866]
of course... if you add one more condition to detect if the key exists... 
it does not change anything on the fact, that R2 is missing one of 
the basic functionalities natively.
Geomol
19-Feb-2012
[2867x2]
Right.
I too wish, more work was put into R2, instead of doing R3. That's 
one reason, why I develop World.
Rebolek
20-Feb-2012
[2869]
That's the problem with closed source languages, if author doesn't 
add something, you're out of luck.