mORMot on ARM (RaspberryPi/BBB)

AOG · 2014-09-07 20:32:31

I am planning to use mORMot for data-logging on some Raspberry Pi and BeagleBone Black computers.

Running the RegressionTests ( Samples; 27 - CrossPlatform Clients; CodeTyphon ) went ok without big problems.

This (inside SynCrossPlatformREST; function FindHeader; nightly 07sep2014):

result := copy(line,length(Name)+1,length(line)-length(Name)-1);

did not work. Change into:

line:=TrimRight(line);
Delete(line,1,length(Name));
result:=line;

and all tests went for 0 failures on Windows and ARM Linux (with the server running on a separate Win8-PC).
All datalogging software will now be adapted for remote logging with mORMot.
(data-flushing / reconnect will be very important for this)
Thank you Arnaud for your CrossPlatform work !!

Question.
The Brook 3.0 framework ([F]CGI and standalone) servers also run without problems on Linux (ARM servers).
Linux mORMot can also communicate with the Linux REST-servers from Brook.

I would welcome a mORMot Linux server, or a possible merge between Brook and mORMot on the server side.
I know this is work in progress.
Could you give an update about your ideas and plans concerning CrossPlatform servers ?

Thanks !

Last edited by AOG (2014-09-07 20:35:34)

ab · 2014-09-08 06:49:48

Pretty weird. The expression is pretty standard and stable IMHO.
Perhaps the issue comes from the fact that the fphttpclient unit has a diverse behavior in ARM and other platforms, and add some spaces...
Did you test with linux on x86?

Could you please test the following:
http://synopse.info/fossil/info/19115f7dee
I do not have any ARM platform at hand, so please tell me if it is not better.

Brook is pretty stable and crossplatform also for its server, since it supports FPC only, but has only a very small subset of features, regarding to mORMot.
You perhaps read the discussion at http://synopse.info/forum/viewtopic.php … 852#p10852 and our blog article at http://blog.synopse.info/post/2014/05/3 … ID-and-OOP
Just compare the number of code lines, and how performance has been optimized, and you will find that those two frameworks can not be fairly compared.

Supporting Linux for server is one of our wishes.
mORMot code is FPC compatible, now most of it compiles, but we do not have time nor money to finish the port.
We can buy some cheap Windows hosting, which would cost less money to us than finishing the FPC/Linux port.

We found out some big issue with string process and newest FPC, at least under Windows.
Just write:

var s,d: RawUTF8;
...
s := 'some UTF-8 content'; // here s has UTF-8 encoding
d := '"'+s+'"'; // now d is not UTF-8 but AnsiString with the Windows code page

Delphi 2009+ is able to handle this as expected.
It should work on Linux, when the system code page is UTF-8.
But it prevent debugging under Windows.

We also found out that the Lazarus debugger is pretty disappointing: for instance, it fails to display the variable content, most of the time, and is difficult to work with.

Some help is welcome, to help going into FPC/Linux.
Consider we do not need it right, and we do not get any money with mORMot.

AOG · 2014-09-08 07:30:02

Your code works for 100% on ARM !
I do not have Linux x86 at the moment. Waiting for the Minnowboard MAX.
(I used TrimRight in my code, because it is [much] cheaper under Delphi, and TSQLRestClientURI.ExecuteAdd works the location header from right to left, and the problems were on the right part of the string).

I did not want to compare Brook and mORMot. I have seen the previous discussions.
I just wanted to make the statement that it should be possible to have mORMot servers running under Linux.
And perhaps with not too much effort.

If I can help, please let me know ... I also do not have the money, but plenty of time !

ps: ARM hardware is very cheap. And a Pi or BeagleBone Black runs very easy headless with Arch Linux (setup consumes few minutes). I can recommend it !

AOG · 2014-09-08 08:58:10

About UTF8 under FPC: could you please state (enlighten) the problem with the help of the (CodeTyphon 4.92) code below ?

procedure TForm1.Button1Click(Sender: TObject);
var
  s,d: RawUTF8;
  e:unicodestring;
begin
  case RadioGroup1.ItemIndex of
    0: begin
         s := '∮ E⋅da = Q,  n → ∞, ∑ f(i) = ∏ g(i)'; // here s has UTF-8 encoding
       end;
    1: begin
         s := 'ᚻᛖ ᚳᚹᚫᚦ ᚦᚫᛏ ᚻᛖ ᛒᚢᛞᛖ ᚩᚾ ᚦᚫᛗ ᛚᚪᚾᛞᛖ ᚾᚩᚱᚦᚹᛖᚪᚱᛞᚢᛗ ᚹᛁᚦ ᚦᚪ ᚹᛖᛥᚫ'; // here s has UTF-8 encoding
       end;
    2: begin
         s := 'ሰማይ አይታረስ ንጉሥ አይከሰስ።'; // here s has UTF-8 encoding
       end;
  end;
  d := '"'+s+'"'; // now d is not UTF-8 but AnsiString with the Windows code page ??
  edit1.Text:=s;
  edit2.Text:=d;
  e:=UTF8Decode(s);
  edit3.Text:=e;
  Edit4.Text:=InttoStr(Length(s));
  Edit5.Text:=InttoStr(Length(d));
  Edit6.Text:=InttoStr(Length(e));
end;

mpv · 2014-09-08 09:40:53

AOG, AB: I also thought a few times about cross platform server. At the moment I agree with AB - we really have cheap Windows hosting and linux server is not my priory. But from my POV the simplest way to port mORMot server to linux is to write descendant of THttpServerGeneric using libuv for IOCP replacement. (only 2000 lines of code in uv.h is much smaller compared to spiderMonkey we port). In future this implementation can replace THttpServer.

ab · 2014-09-08 11:36:18

@mpv
Yes, libuv is a very good library, and should be used for mORMotHTTPServer.pas.
But problems about FPC support are much bigger than the HTTP server itself: even SynCommons.pas does not work as expected, due to diverse RTTI, and some other low-level tricks which won't work.
Even CrossKylix/Kylix, which targets Linux and share the same RTTI than Delphi, is not working as expected yet with SynCommons.

@AOG
Under Windows, with current CodeTyphon, edit2.Text does not contain the expected text, AFAIR.

AOG · 2014-09-08 12:33:30

Strange ... on my PC, edit1 and edit 2 are exactly the same, except for the qoutes !

https://drive.google.com/file/d/0B0llA4 … sp=sharing

ab · 2014-09-08 17:01:30

I was still using the Typhon 4.8 IDE...

The issue seems to be fixed in your edition!

edwinsn · 2014-09-08 18:49:45

mpv, maybe I ask what cheap Windows hosting are you talking about? Last time ab suggested several...

ComingNine · 2014-09-08 21:06:29

ab wrote:

@mpv
Yes, libuv is a very good library, and should be used for mORMotHTTPServer.pas.
But problems about FPC support are much bigger than the HTTP server itself: even SynCommons.pas does not work as expected, due to diverse RTTI, and some other low-level tricks which won't work.
Even CrossKylix/Kylix, which targets Linux and share the same RTTI than Delphi, is not working as expected yet with SynCommons.
@AOG
Under Windows, with current CodeTyphon, edit2.Text does not contain the expected text, AFAIR.

>
> Even CrossKylix/Kylix, which targets Linux and share the same RTTI than Delphi, is not working as expected yet with SynCommons.
>

Does this mean that even if Delphi XE8 has Linux compiler, we cannot produce mORMot-based binary executables to run in Linux OS ?

ab · 2014-09-09 06:15:54

ComingNine wrote:

Does this mean that even if Delphi XE8 has Linux compiler, we cannot produce mORMot-based binary executables to run in Linux OS ?

1. There are indeed still dependencies to the Windows unit. So it won't work directly.

2. I'm not sure Delphi XE8 will have a Linux compiler. If you take a look at the pace of the new features in the recent versions of Delphi, and how it was difficult for them to add 64 bit support for Windows (and not yet for OSX), I would be tempted to say end of 2015.

ComingNine · 2014-09-09 07:30:13

ab wrote:

1. There are indeed still dependencies to the Windows unit. So it won't work directly.
2. I'm not sure Delphi XE8 will have a Linux compiler. If you take a look at the pace of the new features in the recent versions of Delphi, and how it was difficult for them to add 64 bit support for Windows (and not yet for OSX), I would be tempted to say end of 2015.

> 1. There are indeed still dependencies to the Windows unit. So it won't work directly.

Oh ! Thank you for your comments !

> Supporting Linux for server is one of our wishes.
> mORMot code is FPC compatible, now most of it compiles, but we do not have time nor money to finish the port.
> We can buy some cheap Windows hosting, which would cost less money to us than finishing the FPC/Linux port.

Suddenly It feels much less reassuring to use mORMot natively in Linux ...

> 2. I'm not sure Delphi XE8 will have a Linux compiler. If you take a look at the pace of the new features in the recent versions of Delphi, and how it was difficult for them to add 64 bit support for Windows (and not yet for OSX), I would be tempted to say end of 2015.

Thank you for your comments ! They are doing a good job of pushing Delphi forward. Hope they continue or do even better.

Last edited by ComingNine (2014-09-09 07:30:37)

mpv · 2014-09-20 14:06:42

@edwinsn
About hosting - in my country I can hosts on windows starting from $32/Year for example here

mORMot Open Source

#1 2014-09-07 20:32:31

mORMot on ARM (RaspberryPi/BBB)

#2 2014-09-08 06:49:48

Re: mORMot on ARM (RaspberryPi/BBB)

#3 2014-09-08 07:30:02

Re: mORMot on ARM (RaspberryPi/BBB)

#4 2014-09-08 08:58:10

Re: mORMot on ARM (RaspberryPi/BBB)

#5 2014-09-08 09:40:53

Re: mORMot on ARM (RaspberryPi/BBB)

#6 2014-09-08 11:36:18

Re: mORMot on ARM (RaspberryPi/BBB)

#7 2014-09-08 12:33:30

Re: mORMot on ARM (RaspberryPi/BBB)

#8 2014-09-08 17:01:30

Re: mORMot on ARM (RaspberryPi/BBB)

#9 2014-09-08 18:49:45

Re: mORMot on ARM (RaspberryPi/BBB)

#10 2014-09-08 21:06:29

Re: mORMot on ARM (RaspberryPi/BBB)

#11 2014-09-09 06:15:54

Re: mORMot on ARM (RaspberryPi/BBB)

#12 2014-09-09 07:30:13

Re: mORMot on ARM (RaspberryPi/BBB)

#13 2014-09-20 14:06:42

Re: mORMot on ARM (RaspberryPi/BBB)

Board footer