World: r3wp

Ladislav, the two most popular desktop OSes in use today are Windows 
XP and 2000. Both will be and have to be supported by R3, and neither 
is secure enough for a regular person to run without antimalware 
software. We don't want R3 flagged as malware *again* (it already 
happened with one of the early alphas). That is why we are putting 
effort into making R3 more secure.

The R3 process needs to be able to save the %user.r file with the 
current user's permissions in order to allow the user to save their 
preferences. And we don't have a safe place to store the checksum 
of that file to compare against, without also making that checksum 
writeable by the user. That means that the checksum security can't 
be used for %user.r.

It makes me a little sad to realize that in order to keep a copy 
of that early alpha I have to keep it in a passworded compressed 
archive, so antimalware software doesn't delete it. I no longer recommend 
AVG because they refused to remove the false positive from their 
list (they refuse all requests from users of their free products, 
regardless of merit, so you have to buy their paid products to appeal).

The R3 process needs to be able to save the %user.r file with the 
current user's permissions in order to allow the user to save their 
preferences.

 - this is the only one I find relevant as far as security concerns 
 are considered. Nevertheless, this does not contradict what I said 
 in any way I can imagine.

How can any program be secure, if it runs in an insecure environment?

 - by adding its own security constraints, beyond those provided by 
 the environment. We have to support running in an insecure environment 
 since WinXP is such an environment. Oh well.

No matter how well you pretend you are able to run securely in a 
compromised environment, it is not true.

Agreed. You can run more or less securely, but it is really a matter 
of degree. We just don't want to make the extremely common bad decision 
to run WinXP any worse, or else they might blame us for their mistake. 
This has already happened once, so we don't want it to happen again.

Do I understand correctly, that there was somebody catching a virus 
and blaming RT for it?

Yup. The last non-public alpha of R3 was flagged as malware. To this 
day, AVG still refuses to remove the (hopefully) false positive from 
its list.

No wait, it was the first public alpha, not the last non-public one.

if r3 is a virus, it's not spreading very effectively!

Agreed :(

I'm really hoping to get the SECURE function working again before 
the current version gets flagged as well. SECURE has been turned 
off since a108.

Unfortunately R3 is not async

Carl's absence continues to block

Are you serious the SECURE function working may be the difference 
between the R3 being flagged or not?

That looks like a joke to me.

Not really, but then I haven't gotten a straight answer about why 
2.99.4 was flagged either. If you still have a copy of 2.99.4, put 
it in a password-protected compressed archive or else many antimalware 
products will delete it without asking you.

I wish I could find more humor in this though. SECURE not working 
really does bother me a lot; even though I joke about it getting 
R3 flagged as malware, if it actually happened for that reason I 
couldn't argue against that.

Dunno if anyone has the time for a demo contest http://synapse-ehr.com/forums/showthread.php?389-Demo-Competition

Is there any reason why line breaks are allowed inside tag datatype?
>> load {<a^/>}
== <a
>

html specs allow it. whats wrong w that?

especially in xml u might have a lot of attributes.. makes sense 
to break them into lines, doesn't it?

Ah, ok then.

I am not totally frequent here but I have the sense I haven't seen 
any signal from Carl for a long.. am I wrong or did he really go 
silent?

he went silent, yes.

anyone has any idea why or when he will return?

He's probably working on support projects. The last word was that 
it was Linux related. No word on when he will return. He has asked 
us to post the most important bugs in curecode to fix for A112.

aha ok, at least it's a "controlled disapearance"

It usually is. It does seem disconcerting, but last time it lasted 
longer. The result was unicode support in R3. :-)

I was just afraid he stopped communicating and nobody knows what's 
going on

he does that often.

Not sure this one is controlled. This time we are nearing almost 
6-7 months of silence. Carl simply has a day job,not a supporting 
project imo.

Pekr, that is not correct. Last writing was April 1st, 19 days ago.

Janko - Henrik is not right - Unicode "silence" lasted for 3 months. 
Unicode, Parse - those were controlled disappearances, yes. Not this 
one though.

Henrik - last writing where?

RM Asset private world.

I am still not happy with this:

    not none ; == true


, which means, that NOT handles NONE as a logic value. At the same 
time, it is not a logic value for other logic operators/functions:

    none or none

** Script error: or does not allow none! for its value2 argument


, and am tempted to put it to the CureCode. Am I the only one disliking 
this?

To be more precise: I dislike the incompatibility between logic functions, 
not any specific variant of the behaviour.

I can follow that and agree. But it's probably this way, because 
much code will make more sense? Functions returning none in case 
of no more data or the like. Then you can check against none, and 
if the function return ok, you have not none. Or?

I agree, when I look at AND help it states input types as:

(logic! integer! char! tuple! binary! bitset! typeset! datatype!)


none! should be added there and be considered 0 when scalar bitwise 
ANDind is done.

Hmm, Max, that would not help, in fact, keeping the incompatibility 
anyway.

>> if none [42]
== none

>> if not none [42]
== 42

actually, I assumed false was being used that way... it seems not... 

so I vote to have none! be == to #[false] in how logic ops treat 
none.

Geomol, the return value is because of IF...  'IF returns none when 
the condition isn't successfull

yeah, but imagine a function call in stead of none in my code. A 
function, that returns none when failure (like no more data).

Geomol: yes, there *is* a reason why the NOT function is comfortable 
being argument-compatible with IF. But, then, other logic operators/functions 
should be compatible as well. The functionality like typeset or typeset 
can well be left for the UNION function.

Yeah, I understand now. Makes sense to use NONE with OR etc. Because 
it could be the return of a function, we test with OR.

I can't figure right now, if it will lead to some problems in some 
cases.

OR AND etc, already return errors when you try to compare incompatible 
datatypes.  right now it seems very odd to me that #[none] is not 
comparable to logic values.


none is part of the logic! handling in conditionals and loops... 
IMHO it should be in logic ops and funcs too.