World: r4wp

That's my best guess as to where the problem is happening, but I 
haven't gotten to that point yet.

buffer size here https://github.com/gchiu/Rebol3/blob/master/protocols/prot-smtp.r#L66

and sending here https://github.com/gchiu/Rebol3/blob/master/protocols/prot-smtp.r#L284

Thx!

I'm running out of time for this evening.  I may have to hold off 
until Tuesday morning (Monday mornings are crazy for me).

so it waits for the 'wrote event and then once that  happens it writes 
again

which is here and thereafter https://github.com/gchiu/Rebol3/blob/master/protocols/prot-smtp.r#L312

wonder if reducing the buffer size in r3/droid might help?

or arm as it may be

Reducing the buffer size causes breaks at each boundary.  Increasing 
it seems to fix the problem for my attachments less than 64k,

so if it fits inside the buffer size it's ok?

Yes.  If it fits inside the buffer size, it works perfectly.  Tested 
and verified.  It may be fixed in the latest build, but I don't have 
the latest ARM Linux build, and won't have time to build it until 
tomorrow at the earliest.

How about writing to a file and sending to the port and seeing if 
there's a difference ...

so both semi concurrently

I don't have an ARM machine available to test

If I make the buffer 64KB, then there are no problems.

stil need to sort out whether the issue is in the rebol port or userland

Has this been discussed as an R2/R3 change? in R2 the variable used 
in a FOR is hard to mess with:
     for nn 1 5 1 [prin nn nn: 3]
    12345
     for nn 1 5 1 [prin nn unset 'nn]
     12345

But in R3:
     for nn 1 5 1 [prin nn nn: 3]
     144444444444444444444444444444444444444 <esc>
     for nn 1 5 1 [prin nn unset 'nn]
     1** Script error: unset! type is not allowed here

FOR has too many bugs in R2 for me to even want to list them all. 
Is this property something you mind about?

No views on this at all.....Just noticed it as a difference and wondered 
if it was a principle or an accident.

looks like intended (to me)

notice that the value is type-checked

@Robert - do you think Saphirion could put up a newer source download 
if publishing to a repo is not going to happen in the near future?

Yes, sure, that is on the way

a newer download or the public repo?

newer source download

(in the form of a new public repo)

Thanks Ladislav -- looks like someone has put some thought into protecting 
the datatype (though not the range) of the word used in an R3 FOR 
loop.

(actually, it was me who explained Carl why the typecheck was absolutely 
necessary)

Regarding the question whether it is better to protect the value 
of the cycle variable - I tend to think that it does not make sense 
to "overprotect" the programmer. That might just make the dycle less 
convenient in some cases.

You should not understand it so that we discussed the FOR loop behaviour 
- I demonstrated the typecheck necessity on a different example, 
which Carl noted and used in the FOR case as well.

Also, in my opinion REPEAT is a special case of FOR and note that 
in R3 REPEAT and FOR are compatible, which is not the case in R2.

Pekr: "BrianH:I don't believe a single second for R3 becoming even 
beta. Three or so years ago I wrote, what makes a good beta for me. 
So here it comes - give me a console, not a crap. Give me smtp, ftp 
etc schemes, without an excuse. Give us odbc, mysql, postgress, give 
us CALL. So - no matter how much advanced R3 is to R2, in a sence 
of a complete package, it is still pre-alpha ..."

For the moment ignoring that development was put on hold for at least 
2 years, let's discuss this. I agree with you.

The one thing I don't agree with is "give us". It's a community project 
now, for real this time. There is no "give us", we give it to ourselves.

But you are talking about very high-level features. R3 is designed 
to be modular, so most things that need to be built-in features in 
R2, should be add-on modules or extensions in R3, even the ones that 
we include by default. And some of what you request has been started 
already, such as the database stuff which ChristianE started, and 
I have been using every day for more than a year.

But yes, we need more schemes (also in included-by-default modules) 
and a decent CALL, agreed.

And a better console, built on R3-GUI. And better text-mode console 
support for systems where you can't use a GUI.

BrianH: well, I was long time a proponent of R3. What attracted me 
most were devices, even more modularity, etc. But - let's not be 
deluded. If you are careful enough, you could see, that ppl mention 
some things here or in regards to Red, eg. asking - is View going 
to be available? Let's not ingore, that many ppl started to use REBOL, 
because it was kind of complete package - console, call, dbases, 
networking, gui ...

Still, all of that can be added on or retrofitted, that's the whole 
point of being modular. Having them implemented and available before 
3.0 would be a good idea for marketing reasons (don't knock those, 
they're important), but not having them done before 3.0 won't break 
user code the way not doing core semantic changes before 3.0 would. 
People will be working on these before 3.0 comes out because they 
need them, and the ones that we as a community consider to be the 
most important to include in 3.0 will likely be worked on the most. 
But the great part about that stuff is that it doesn't have to be 
developed as part of R3 itself, just like the GUI is being developed 
separately.

Personally, I want to work on the database support because that is 
what I need the most and have the most experience with. I expect 
that others will need networking stuff more, and yet others will 
need CALL or a better console.

The situation is the same for Red. Kaj or anyone other maight claim, 
that we have CURL networking. But for me, that is not the REBOL I 
want. I want port/schemes abstraction, period, or it is not REBOL 
like environment for me. It does the job, but so does ASP .net. You 
are one of the top developers for R3. I want you to know my opinion 
(maybe I am alone feeling that way, and that is fair enough), so 
- let's use what defined REBOL - ports as an abstraction mechanism, 
schemes upon that, etc.

I agree with BrianH, and I also can see where Pekr is coming from.

I'm not a C developer, so I don't feel like I can do much to add 
to the sources of R3.  However, what attracts me to Rebol, and what 
makes me want to use Rebol, is that I can do just about anything 
with relative ease.

<Complete package ...etc> It's interesting that the fact that REBOL 
would have many schemes was part of the original vision / marketing:

   http://web.archive.org/web/19980530155104/http://www.rebol.com/news.html

There is no such thing as a complete package anymore. Things are 
changing too quickly, and in too many directions. People need the 
stuff they need, and they need to *not have* the stuff they *don't* 
need. There are too many completely different platforms now. We can't 
afford to be monolithic anymore, since that will just mean that we 
won't be compatible with what most developers need to do, since most 
developers need to do stuff that is incompatible with what most other 
developers need to do.

Bo - do you remember first CID? Predecessor of VID? I can remember 
small script, which was showing image from 4 webcams, in rudiculously 
small script. That was - rebollish :-)

For instance, most developers need to have support for either SQL-like 
databases, or NoSQL databases (according to many different data models), 
or both, but they are not compatible with each other even in theory 
once you get out of SQL world.

BrianH: well, as for many scenarios, I can accept SDK like environment, 
where I choose, what to include, but for some ppl, some R3.exe should 
exist, which should contain some agreed upon functionality. If we 
go just with the opinion of let's have bare bone core.exe, and the 
rest via some includes, that scares hell out of me, really. That's 
like other languages, loosing what made REBOL rebolish.

Nope, I want an includes-everything-reasonable prebuilt interpreter, 
even if a lot of it won't actually be loaded by default until you 
choose to import it (from inside, we have delay-loading). But that 
will just be one (official) set of applications made with the greater 
application construction kit, like the R2 SDK.