AltME groups homeHelpJoin REBOL3 world
  Find AltME posts   Help

Recent posts

Worlds:r4wpr3wp
AccessibilityAbout / FAQ
Member's loungeContact/FeedbackOther REBOL links
Membership:
member name

password

Remember?

Not a member? Please join
16-May 8:48 UTC
[0.078] 21.96k
r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

Join the discussions in the REBOL3 world...

[Core] Discuss core issues

older
newer		first
last
Janeks
30-Jun-2008
[10737]
I am working on sript, that composes and sends html e-mail.

It is rather simple, but now I would like that e-mail will contain 
inline images.

I found out that they are multipart messages, and that image is referenced 
with cid in html image and in image part it is marked as Content-ID:

</HEAD>
<BODY bgColor=3D#ffffff>

<DIV><FONT face=3D"Courier New" size=3D2></FONT><IMG height=3D47=20
src=3D"cid:26DB76551F2E4591BBC3B599C3A7CCAE" width=3D320></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
</BODY></HTML>

------=_NextPart_001_00A9_01C8DAAB.A817E460--

------=_NextPart_000_00A8_01C8DAAB.A817E460
Content-Type: image/bmp;
	name="ML.bmp"
Content-Transfer-Encoding: base64
Content-ID: <26DB76551F2E4591BBC3B599C3A7CCAE>


Qk22vQEAAAAAADYAAAAoAAAADwIAAEgAAAABABgAAAAAAIC9AQDEDgAAxA4AAAAAAAAAAAAA////

////////////////////////////////////////////////////////////////////////////

How to implement such html e-mail generation in rebol script?
Graham
30-Jun-2008
[10738]
the send/attach can generate the multipart components for you.
Janeks
30-Jun-2008
[10739]
O'k. But how to put Content -ID into message part?
Gregg
30-Jun-2008
[10740]
Alan Dechert <[dechert-:-gmail-:-com]> asked the same thing on the ML earlier 
this month. Maybe the two of you can collaborate on a solution. If 
you could enhance SEND to allow it, maybe with a new refinement, 
we can try to get Carl to make it the standard.
Graham
1-Jul-2008
[10741x3]
Anyone know how to use sort on some data where eg. skip value is 
10 and you want to sort of anything but the first element?

Looks like the comparator function takes two arguments ... which 
are the first of each set

Ok, sussed it out .. the compare can be an integer offset
Janeks
2-Jul-2008
[10744]
What is the right way to check  is port (ODBC, mySQL) open?
Is it a-port/port-id ?
Gregg
2-Jul-2008
[10745]
There's no official way. I think DocKimbel had a value in flags or 
state that he said worked. If he doesn't jump in, I'll dig for it.
james_nak
2-Jul-2008
[10746]
Janeks, Dockimbel recently put some code in the MySql group regarding 
how to check for Mysql port being opened.
Henrik
7-Jul-2008
[10747]
has anyone worked on a method to convert a rebol block to a php array 
inside php?
Dockimbel
8-Jul-2008
[10748x3]
For checking if a port! value is "opened", you can use this function 
: open?: func [port][zero? port/state/flags and 1024]. But that just 
checks for the "close" flag, it doesn't check the real TCP connection 
state.

>> p: open http://rebol.com
>> open? p
== true
>> close p
>> open? p
== false

In this example, it does report correctly the port state, but that 
doesn't inform you about the underlying TCP connection state (the 
TCP connection is closed once the first line is completed).
TimW
9-Jul-2008
[10751]
Is there a way to specify precision with rounding?   My specific 
example has to do with money.  Not only does it always chop it off 
to exact cents, but it rounds down.  so .125 -> $0.12   This is horrible 
for accounting purposes.  I just put everything in decimal and completely 
ignore the money! datatype, but this seems like a real shame.  So 
is it possible to specify the decimal out to 4 or 5 places?
Graham
9-Jul-2008
[10752]
help round
TimW
9-Jul-2008
[10753]
'round still doesn't work with money though >> round/to to-money 
.125 .001  --> $0.12
Henrik
9-Jul-2008
[10754]
Tim, it's probably better to not use money! when rounding.
Sunanda
9-Jul-2008
[10755x2]
The rounding may not be to exact cents -- money type only *displays* 
2 decimal points, though it *preserves* more:
   to-money .125
   == $0.13
   second to-money .125
   0.125

Also, I am not seeing the always-down effect you report.
   round/to $.125 .001
   == $0.13    ;; correctly rounded up


Round did go through a couple of development stages. Perhaps your 
version of REBOL has an outdated one. This is the source from the 
version I am using:

round: func [

    {Returns the nearest integer. Halves round up (away from zero) by 
    default
.}
    [catch]
    n [number! money! time!] "The value to round"
    /even "Halves round toward even results"

    /down {Round toward zero, ignoring discarded digits. (truncate)}
    /half-down "Halves round toward zero"
    /floor "Round in negative direction"
    /ceiling "Round in positive direction"
    /half-ceiling "Halves round in positive direction"
    /to "Return the nearest multiple of the scale parameter"
    scale [number! money! time!] "Must be a non-zero value"
    /local m
][
    throw-on-error [
        scale: abs any [scale 1]
        any [number? n scale: make n scale]
        make scale either any [even half-ceiling] [
            m: 0.5 * scale + n
            any [
                all [
                    m = m: m - mod m scale
                    even
                    positive? m - n
                    m - mod m scale + scale
                ]
                m
            ]
        ] [
            any [
                floor
                ceiling

                (ceiling: (found? half-down) xor negative? n down)
                n: add n scale * pick [-0.5 0.5] ceiling
            ]

            either ceiling [n + mod negate n scale] [n - mod n scale]
        ]
    ]
]
Henrik
9-Jul-2008
[10757]
As a note: In R3, money! is of much greater precision (infinite?) 
and should round properly using conventional ROUND/TO (once bug #492 
is fixed, that is :-)).
Pekr
9-Jul-2008
[10758]
infinite = 27 positions, IIRC ...
Henrik
9-Jul-2008
[10759]
thanks, couldn't remember
Chris
13-Jul-2008
[10760x2]
Uck, this is unsightly:

	>> to-path [
	[    a
	[    b
	[    c
	[    ]
	==
	a/
	b/
	c

Why does it not result in:

	== a/b/c
[unknown: 5]
13-Jul-2008
[10762x2]
The newline character is being detected so it is treating each as 
a separate statement.  I would think that isn't a bug but rather 
a feature.

Since the following works fine:

>> to-path [a b c]
== a/b/c
Chris
13-Jul-2008
[10764x4]
I think it's a bug in to-path.  Why would you possibly want to retain 
that behaviour?

I can understand silently storing newline settings between block 
sessions (I use 'new-line a little to control this behaviour), but 
what scenarios benefit from this when working with paths?

Consider this scenario:

	countries: [
		us "United States"
		fr "France"
		au "Australia"
		uk "United Kingdom"
	]

	foreach code extract countries 2 [
		probe form to-path compose to-block 'users/(code)
	]

I know how to work around it, just don't see the purpose.
Gabriele
14-Jul-2008
[10768]
chris, there is no purpose, it's just that internally path! = block!, 
so path! behaves exactly like block! does. it probably should strip 
newlines when converting though, or at least ignore them when molding... 
(that is, i'm saying this is a bug.)
Henrik
14-Jul-2008
[10769]
perhaps it's a good idea to check on any char that does not belong 
in a path! R3 has a bug where it includes none! as part of a path.
[unknown: 5]
14-Jul-2008
[10770]
Chris, you raised a good point when you said "Why would you possibly 
want to retain that behavior?".  We wouldn't - add it to RAMBO please.
Chris
14-Jul-2008
[10771]
Gab: just want to be sure, I know that one man's bug is another man's 
feature...
eFishAnt
14-Jul-2008
[10772]
I'll RebIT to that!
TimW
17-Jul-2008
[10773]
sorry I didn't reply sooner.  The version of round I was using was 
on a linux box so it was the latest debian rebol release.  It does 
round up correctly on the windows version I have.
Henrik
21-Jul-2008
[10774x2]
>> build-tag [input type checkbox value test checked] 
== <input type="checkbox" value="test" checked> ; OK

>> build-tag [input type checkbox value test checked /]

== <input type="checkbox" value="test" checked="/"> ; Not OK, but 
required in all XHTM Lstandards.

I'm not sure if it's the best way, but could it be solved by checking 
for /, "/" or #"/" as well as tail position in the block.
Geomol
21-Jul-2008
[10776]
What do you mean?
Henrik
21-Jul-2008
[10777]
what I mean is that for single-standing tags, like <br>, XHTML 1.0 
and upwards requires them to end with a slash. This creates a correct 
tag for this case:

>> build-tag [input type checkbox value test /]
== <input type="checkbox" value="test" />

But this is not correct:

>> build-tag [input type checkbox value test checked /]
== <input type="checkbox" value="test" checked="/">
[unknown: 5]
21-Jul-2008
[10778]
build-tag was probably adapted to support the earlier specification.
Davide
21-Jul-2008
[10779]
The correct tag required by XHTML is:
>> build-tag [input type checkbox value test checked checked /]
== <input type="checkbox" value="test" checked="checked" />
Henrik
21-Jul-2008
[10780x2]
is checked="checked" really correct?

interesting. it is correct.
Chris
21-Jul-2008
[10782]
Yep, xhtml requires paired attributes.
Graham
23-Jul-2008
[10783]
>> f: %"test dir"
== %test dir
>> make-dir f
== %test dir/
>> read f
** Access Error: Cannot open /d/rebol/test dir
** Near: read f
Henrik
23-Jul-2008
[10784]
I'd say it's a bug
Graham
23-Jul-2008
[10785]
a very old bug
Henrik
23-Jul-2008
[10786]
but good it was found. that revealed 4 bugs in R3 there. :-)
older
newer		first
last