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

World: r3wp

[Core] Discuss core issues

Pekr
26-Jun-2006
[4996]
Volker - isn't checking against the calendar too preliminary during 
the state of code load? :-)
Volker
26-Jun-2006
[4997]
No, thats the basic equpment of a god loader. pda and such ;)
Pekr
26-Jun-2006
[4998x3]
:-)
even a cell phone? probably so :-)
in the case of tuple, is that kind of binary given, that the value 
can't be larger than 255?
Volker
26-Jun-2006
[5001x3]
*riing* "Hi" - "This isnt a date, you know?" :)
Yes.
upto 12 bytes  out the 16 AFAIK.
Pekr
26-Jun-2006
[5004]
so tuples can't be used for things like coordinaty space?
Volker
26-Jun-2006
[5005x3]
No.
Coimplex things need objects.
Until Carl finds a clever magic new way to keep performance. :)
Pekr
26-Jun-2006
[5008x2]
hmm, we have pair for such things ...
I wonder if tuples should allow rotation?
Volker
26-Jun-2006
[5010x2]
the advantage is, the memory-layout is known, so the interpreter 
has an easier job.
Hmm, shifting would be nice. I use them for version-numbers and colors, 
so i dont need rotation. but getting at thepart with the os would 
help. What usage benefits from rotation?
Pekr
26-Jun-2006
[5012]
dunno, but I saw someone mentioning the need for it already ...
DideC
26-Jun-2006
[5013x2]
A language is not there to solve any particular needs, but to solve 
the needs of most of us

Not the original sentence, but Carl said something like that, one 
day (maybe in a blog, or what is Altme?).
As a comment, try "29/02/2006" in Excel and it will give you a nice 
"text" value, not a date value.
Don't expect 'load to make this kind of choice !
Gabriele
26-Jun-2006
[5015x2]
Petr, it's not "non recoverable", it's perfectly recoverable, you're 
just trying to recover when it is too late.
load must make sure that the date is correct, because it must convert 
it to the internal format. 29-Feb-2006 simply cannot be converted 
and thus cannot be loaded.
Ladislav
26-Jun-2006
[5017]
Pekr: "I am not talking about string..." - Wrong! You are talking 
about string but refuse to admit it. Every source code is a string 
before LOAD transforms it to a block. (see my articles on this)
Edgar
26-Jun-2006
[5018]
Like Pekr, I am confused here. It would seem that if the loader cannot 
convert a value into the internal format, then it should have a fall 
back of loading it as a string. Other values that Rebol can't convert 
to an internal datatype should convert it to a string to be consistent.
Anton
26-Jun-2006
[5019x2]
That would cause rather strange bugs. Quite often, you wouldn't notice 
that you had made a syntax error. How would you know whether a string 
was an incorrectly written date or just some other string ? eg:  
How could you tell whether   "jan 12"  was intended to be a date! 
or not ? Maybe it's somebody's name and age in a string.
I am completely happy with the way load works in this regard. A given 
date string must comply with the rebol syntax and have valid sub-values 
otherwise I don't want it. If messy data is coming in, just catch 
errors loading it from a string. Simple.
BrianH
26-Jun-2006
[5021x2]
Petr, 29-Feb-2006 is always an invalid date. You can't say "Under 
some condition it could be even valid date (leap year)" because the 
year 2006 is specified in that date, and 2006 is not a leap year.


Data types have syntactic forms and semantic constraints. In order 
for the loader to recognize the data type, the syntactic form must 
be followed. In order for the resulting data to be valid, the semantic 
constraints must be obeyed. One such constraint is that date! values 
must correspond to a date on the calendar. Semantic violations are 
the bugs that all of that nasty exploit code does its job.
Sorry, "code uses to do its job."
Ingo
26-Jun-2006
[5023]
Well, I checked with my paper-based calendar, and it isn't able to 
hancle 2006-02-29 either.So it may be OK that way ;-)
Gabriele
27-Jun-2006
[5024x3]
load-relaxed: func [string /local res sp parseblk] [
    sp: charset " ^/^-"
    parseblk: func [blk string /local val] [
        parse string [
            some [

                #"[" string: (string: parseblk val: make block! 16 string append/only 
                blk val) :string
                |

                #"(" string: (string: parseblk val: make paren! 16 string append/only 
                blk val) :string
                |

                #"]" string: (either block? blk [return string] [append blk "]"])
                |

                #")" string: (either paren? blk [return string] [append blk ")"])
                |

                string: skip (either error? try [set [val string] load/next string] 
                [

                    append blk copy/part string string: any [find string sp tail string]
                ] [
                    append blk :val
                ]) :string
            ]
        ]
        string
    ]
    parseblk res: make block! 16 string
    res
]
>> load-relaxed {10-Feb-2006 20-Feb-2006 29-Feb-2006 1-Mar-2006}
== [10-Feb-2006 20-Feb-2006 "29-Feb-2006" 1-Mar-2006]

>> load-relaxed {10-Feb-2006 20-Feb-2006 [29-Feb-2006 1-Mar-2006]}
== [10-Feb-2006 20-Feb-2006 ["29-Feb-2006" 1-Mar-2006]]
(just to give an idea)
Pekr
27-Jun-2006
[5027]
thanks :-)
Anton
27-Jun-2006
[5028]
so... what are you going to do with "29-Feb-2006" ?
Pekr
2-Jul-2006
[5029x3]
hmm, why send/attach sends jpeg in some non standard way? When I 
normally receive jpeg, first it is related to jpeg icon, second it 
is displayed in my email directly ....
ah, the difference is:

Content-Type: image/jpeg; name="2.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="2.jpg"

--__REBOL--View--1.3.2.3.1--5318724__
Content-Type: application/octet-stream; name="bay.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="bay.jpg"
rebol does not recognise filetype .... so it uses application/octec-stream 
.... too many gotchas here, maybe it would be better to construct 
complete headers. Will look into some alternative attachment sending 
scripts on rebol.org ....
Anton
2-Jul-2006
[5032x2]
Rebol doesn't have a jpeg datatype, so you would have to specify 
Content-Type to SEND.
Yes, look for another example which does this already.
Pekr
2-Jul-2006
[5034]
thanks .... have you ever heard of this cid: protocol thingy?
Volker
2-Jul-2006
[5035]
source send
source build-attach-body
source make-mime-header
;now to find that..
Pekr
2-Jul-2006
[5036x2]
ah, build-attach-body ... did not know there are other functions 
involved ...
however, I can't parametrise 'send further, so ....
Volker
2-Jul-2006
[5038]
but you can check for suffix maybe
Pekr
2-Jul-2006
[5039]
I can adapt thouse functions probably though ... I need to make different 
headers .... build-attach-body uses application/octect-stream, without 
ability to parametrise for e.g.
Anton
2-Jul-2006
[5040]
How come you are sending JPEGs ? I thought you would want to keep 
open the possibility of creating your postcard images using rebol, 
therefore it's better to get PNG working, isn't it ?
Pekr
2-Jul-2006
[5041x4]
not sure .... but it could be so ....
simply the plan is - get jpeg (source file), compose with text, send 
inline, not even as an attachement. It is just that I did not heard 
about cid: container email reference before ... do all mailers handle 
pngs?
I am also not sure, how many ppl has turned off ability to display 
html content in email .... maybe it would be better to actually not 
send post-card .... but post a link to on-server stored image?
I will play with what was requested (sending an image) and I will 
see how can I handle it ...
Volker
2-Jul-2006
[5045]
There is also something like an inline-image inside the tag.