Project status
lessless opened this issue · comments
Hello peeps,
It's a sorrow to see that such extraordinaire project isn't being updated! What is the current status and future plans?
All recent updates to the code were customer-driven. New users mean new updates. The likely application area for this is NFV, modular software for telecoms. No definite plans,
@maximk You might find the following post interesting, given that you mention NFV. You probably met Wassim and Heikki at SCaLE.
http://unikernel.org/blog/2016/unikernel-nfv-platform
it's sad to see such a peace rotting here … so i would offer my open source time to work here but i'm kinda new to unikernels … but if someone will give me a hand here to start and how - i would love to keep this running.
@bmalum I'm glad to help, I'm available at https://gitter.im/cloudozer/ling or in personal messaging there.
P.S. I took part in developing LING in the past.
I too would like to revive this project. I have been trying to bring this to V19 of Erlang but running into compile time issues when running 'railing image'. Any pointers or doc or anything to point me in the right direction would be amazing...
Please. Zero OS unikernels is very important. Not the least being practically zero attack surface.
@EarlGray Let me ask you, if you were tasked to bring LING to V19, where would you start? I tried the simple, get it to compile under the latest revs, fixed all the warnings, added Erlang:time stamp as a BIF... all seemed ok but running Railing generates an exception in one of the encoding beam encoding libraries... Where could you point me?
Thanks for any help...
You can send the error logs to me. If it is something that only takes an
hour I will help you out. --Maxim
…On Sat, Mar 18, 2017 at 8:01 PM, Stephane Bourque ***@***.***> wrote:
@EarlGray <https://github.com/EarlGray> Let me ask you, if you were
tasked to bring LING to V19, where would you start? I tried the simple, get
it to compile under the latest revs, fixed all the warnings, added
Erlang:time stamp as a BIF... all seemed ok but running Railing generates
an exception in one of the encoding beam encoding libraries... Where could
you point me?
Thanks for any help...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAEFTAvo4SvJMXb_-uM3uMTcW3u04h11ks5rnBvtgaJpZM4ImGyY>
.
@maximk Thanks for helping...
Here is the first significant warning
core/ling_main.c: In function ‘proc_main’:
core/ling_main.c:5678:3: warning: array subscript is above array bounds [-Warray-bounds]
rs[1022] = *(term_t *)expand_ptr(tmp_arg1);
^
core/ling_main.c:5976:7: warning: array subscript is above array bounds [-Warray-bounds]
if (rs[1022] != (term_t)ip[2])
^
Now changing NUM_REGS to 1024 fixes the warning, but I see some significance to 1022.
Here is the error when running railing image for cowboy's hello_world example.
_Compile: rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam
escript: exception error: no function clause matching ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233)
in function ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231)
in call from ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231)
in call from ling_lib:encode/1 (bc/ling_lib.erl, line 231)
in call from ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174)
in call from ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125)
in call from railing:compile/2 (railing/railing.erl, line 399)
in call from railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)
This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too.
I compiled LING with the latest build-essential, using Erlang V19.2
I added a new BIF for erlang:timestamp() (I just duplicated what was there for erlang:now() ).
Let me know if you need anything else.
Thanks
This is likely a change to the Erlang compiler introduced in R19.
The compiler used to emit references to a 'temporary' registers, such as
r1024 despite the fact that there are only 256 registers. Maybe, now
compiler emit references to more of such short-lived out-of-bound registers.
Anyways, the investigation and correction will take considerable time I do
not have now.
Regards,
M
…On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque ***@***.***> wrote:
@maximk <https://github.com/maximk> Thanks for helping...
Here is the first significant warning
*core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3:
warning: array subscript is above array bounds [-Warray-bounds] rs[1022] =
*(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning: array
subscript is above array bounds [-Warray-bounds] if (rs[1022] !=
(term_t)ip[2]) ^*
Now changing NUM_REGS to 1024 fixes the warning, but I see some
significance to 1022.
Here is the error when running railing image for cowboy's hello_world
example.
_Compile:
*rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam escript:
exception error: no function clause matching
ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in function
ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call from
ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call from
ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from
ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from
ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from
railing:compile/2 (railing/railing.erl, line 399) in call from
railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)*
This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too.
I compiled LING with the latest build-essential, using Erlang V19.2
I added a new BIF for erlang:timestamp() (I just duplicated what was there
for erlang:now() ).
Let me know if you need anything else.
Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY>
.
Thanks for looking into this Maxim.
I am still interested. If you could point me in the right direction, I
would love to investigate and see if I can address this issue.
I assume I need to look for changes in Beam in R19 to previous revs. Are
there some additional docs for Ling and how it differs from Beam?
I appreciate any info..
On Tue, Mar 21, 2017 at 19:08 Maksym Kharchenko <notifications@github.com>
wrote:
… This is likely a change to the Erlang compiler introduced in R19.
The compiler used to emit references to a 'temporary' registers, such as
r1024 despite the fact that there are only 256 registers. Maybe, now
compiler emit references to more of such short-lived out-of-bound
registers.
Anyways, the investigation and correction will take considerable time I do
not have now.
Regards,
M
On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque <
***@***.***>
wrote:
> @maximk <https://github.com/maximk> Thanks for helping...
>
> Here is the first significant warning
>
>
>
>
>
>
>
> *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3:
> warning: array subscript is above array bounds [-Warray-bounds] rs[1022]
=
> *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning:
array
> subscript is above array bounds [-Warray-bounds] if (rs[1022] !=
> (term_t)ip[2]) ^*
>
> Now changing NUM_REGS to 1024 fixes the warning, but I see some
> significance to 1022.
>
> Here is the error when running railing image for cowboy's hello_world
> example.
>
> _Compile:
>
>
>
>
>
>
>
> *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam escript:
> exception error: no function clause matching
> ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in function
> ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call
from
> ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call
from
> ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from
> ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from
> ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from
> railing:compile/2 (railing/railing.erl, line 399) in call from
> railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)*
>
> This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too.
>
> I compiled LING with the latest build-essential, using Erlang V19.2
>
> I added a new BIF for erlang:timestamp() (I just duplicated what was
there
> for erlang:now() ).
>
> Let me know if you need anything else.
>
> Thanks
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#141 (comment)>,
or mute
> the thread
> <
https://github.com/notifications/unsubscribe-auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABxfxBljYA4K70vAJorykcvY14vgcm58ks5rn6-fgaJpZM4ImGyY>
.
Stephane,
I have found a possible fix for you. See bc/ling_code.erl lines 90-91. It
converts reg 1023 (non-existent) to reg 255 (rarely used). It is a hack in
the same vein as reg 1023 is a hack. You can add another case to convert
reg 1022 to reg 254.
A few comments on how LING and BEAM differ:
1. Both LING and BEAM use the same high-level instruction set you can see
when you disassemble BEAM files. However, it is not the instruction set VMs
execute. They execute highly-optimized low-level instructions and these are
different between LING and BEAM. The low-level instruction set for LING is
bc/iops.tab.
2. BEAM translates from high-level to low-level instructions upon module
load. For this it uses a sophisticated engine similar to a Prolog
interpreter. LING does the translation statically upon compilation of the
module. .ling files contain low-level instructions. The goal of the
approach is to make LING start faster.
3. Both BEAM and LING use specialized 'variants' for low-level
instructions. For instance, there may be instruction variant to add a
register to reg0 and a more general variant to add two arbitrary registers.
The difference is that BEAM enumerates all instruction variants
statically. LING 'discovers' optimal instruction variants by collecting
statistics on a body of Erlang sources (stdlib). More variants allow the C
compiler produces a faster code, but at the same time increase the code
size of the interpreter. You can see discovered instruction variants in
bc/ling_iopvars.erl (after the build).
4. The main source of LING interpreter is core/ling_main.c. The file is
generated to accommodate for all instruction variants discovered earlier.
Regards,
M
On Sat, Mar 25, 2017 at 2:33 AM, Stephane Bourque <notifications@github.com>
wrote:
… Thanks for looking into this Maxim.
I am still interested. If you could point me in the right direction, I
would love to investigate and see if I can address this issue.
I assume I need to look for changes in Beam in R19 to previous revs. Are
there some additional docs for Ling and how it differs from Beam?
I appreciate any info..
On Tue, Mar 21, 2017 at 19:08 Maksym Kharchenko ***@***.***>
wrote:
> This is likely a change to the Erlang compiler introduced in R19.
>
> The compiler used to emit references to a 'temporary' registers, such as
> r1024 despite the fact that there are only 256 registers. Maybe, now
> compiler emit references to more of such short-lived out-of-bound
> registers.
>
> Anyways, the investigation and correction will take considerable time I
do
> not have now.
>
> Regards,
> M
>
>
> On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque <
> ***@***.***>
> wrote:
>
> > @maximk <https://github.com/maximk> Thanks for helping...
> >
> > Here is the first significant warning
> >
> >
> >
> >
> >
> >
> >
> > *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3:
> > warning: array subscript is above array bounds [-Warray-bounds]
rs[1022]
> =
> > *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning:
> array
> > subscript is above array bounds [-Warray-bounds] if (rs[1022] !=
> > (term_t)ip[2]) ^*
> >
> > Now changing NUM_REGS to 1024 fixes the warning, but I see some
> > significance to 1022.
> >
> > Here is the error when running railing image for cowboy's hello_world
> > example.
> >
> > _Compile:
> >
> >
> >
> >
> >
> >
> >
> > *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam
escript:
> > exception error: no function clause matching
> > ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in
function
> > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call
> from
> > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call
> from
> > ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from
> > ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from
> > ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from
> > railing:compile/2 (railing/railing.erl, line 399) in call from
> > railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)*
> >
> > This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too.
> >
> > I compiled LING with the latest build-essential, using Erlang V19.2
> >
> > I added a new BIF for erlang:timestamp() (I just duplicated what was
> there
> > for erlang:now() ).
> >
> > Let me know if you need anything else.
> >
> > Thanks
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#141 (comment)>,
> or mute
> > the thread
> > <
> https://github.com/notifications/unsubscribe-
auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY
> >
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#141 (comment)>,
or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/
ABxfxBljYA4K70vAJorykcvY14vgcm58ks5rn6-fgaJpZM4ImGyY>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAEFTOY5ys2v8B21MEzEQiQQk9M0ho_qks5rpGDxgaJpZM4ImGyY>
.
Fantastic Maxim!
Made the suggested change and all compiles. Railing works. The generated
image crashes during an assert() in proc_make line 61, ... core/proc.c The
image then freezes up...
Do you know if there is a reason or something would be limiting running
LING on 32 bit OS? Or compiled in 32 bit mode? I see a lot of casting to
(u_int32) and memory compares and for sure this would fail on 64 bit OS. Am
I out to lunch? Am I missing some flag when starting the image?
Thanks again...
On Sat, Mar 25, 2017 at 3:03 AM Maksym Kharchenko <notifications@github.com>
wrote:
Stephane,
I have found a possible fix for you. See bc/ling_code.erl lines 90-91. It
converts reg 1023 (non-existent) to reg 255 (rarely used). It is a hack in
the same vein as reg 1023 is a hack. You can add another case to convert
reg 1022 to reg 254.
A few comments on how LING and BEAM differ:
1. Both LING and BEAM use the same high-level instruction set you can see
when you disassemble BEAM files. However, it is not the instruction set VMs
execute. They execute highly-optimized low-level instructions and these are
different between LING and BEAM. The low-level instruction set for LING is
bc/iops.tab.
2. BEAM translates from high-level to low-level instructions upon module
load. For this it uses a sophisticated engine similar to a Prolog
interpreter. LING does the translation statically upon compilation of the
module. .ling files contain low-level instructions. The goal of the
approach is to make LING start faster.
3. Both BEAM and LING use specialized 'variants' for low-level
instructions. For instance, there may be instruction variant to add a
register to reg0 and a more general variant to add two arbitrary registers.
The difference is that BEAM enumerates all instruction variants
statically. LING 'discovers' optimal instruction variants by collecting
statistics on a body of Erlang sources (stdlib). More variants allow the C
compiler produces a faster code, but at the same time increase the code
size of the interpreter. You can see discovered instruction variants in
bc/ling_iopvars.erl (after the build).
4. The main source of LING interpreter is core/ling_main.c. The file is
generated to accommodate for all instruction variants discovered earlier.
Regards,
M
On Sat, Mar 25, 2017 at 2:33 AM, Stephane Bourque <notifications@github.com>
wrote:
Thanks for looking into this Maxim.
I am still interested. If you could point me in the right direction, I
would love to investigate and see if I can address this issue.
I assume I need to look for changes in Beam in R19 to previous revs. Are
there some additional docs for Ling and how it differs from Beam?
I appreciate any info..
On Tue, Mar 21, 2017 at 19:08 Maksym Kharchenko ***@***.***>
wrote:
> This is likely a change to the Erlang compiler introduced in R19.
>
> The compiler used to emit references to a 'temporary' registers, such as
> r1024 despite the fact that there are only 256 registers. Maybe, now
> compiler emit references to more of such short-lived out-of-bound
> registers.
>
> Anyways, the investigation and correction will take considerable time I
do
> not have now.
>
> Regards,
> M
>
>
> On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque <
> ***@***.***>
> wrote:
>
> > @maximk <https://github.com/maximk> Thanks for helping...
> >
> > Here is the first significant warning
> >
> >
> >
> >
> >
> >
> >
> > *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3:
> > warning: array subscript is above array bounds [-Warray-bounds]
rs[1022]
> =
> > *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning:
> array
> > subscript is above array bounds [-Warray-bounds] if (rs[1022] !=
> > (term_t)ip[2]) ^*
> >
> > Now changing NUM_REGS to 1024 fixes the warning, but I see some
> > significance to 1022.
> >
> > Here is the error when running railing image for cowboy's hello_world
> > example.
> >
> > _Compile:
> >
> >
> >
> >
> >
> >
> >
> > *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam
escript:
> > exception error: no function clause matching
> > ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in
function
> > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call
> from
> > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in call
> from
> > ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from
> > ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from
> > ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from
> > railing:compile/2 (railing/railing.erl, line 399) in call from
> > railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)*
> >
> > This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too.
> >
> > I compiled LING with the latest build-essential, using Erlang V19.2
> >
> > I added a new BIF for erlang:timestamp() (I just duplicated what was
> there
> > for erlang:now() ).
> >
> > Let me know if you need anything else.
> >
> > Thanks
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#141 (comment)>,
> or mute
> > the thread
> > <
> https://github.com/notifications/unsubscribe-
auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY
> >
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#141 (comment)>,
or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/
ABxfxBljYA4K70vAJorykcvY14vgcm58ks5rn6-fgaJpZM4ImGyY>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or
mute
the thread
<
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABxfxBjZo0MxWXvzmLBy_HP5G_KHFH2Lks5rpOZVgaJpZM4ImGyY>
.
Historically, LING started as 32-bit only. The porting to 64-bit was easy
(half a day), but later I dropped the 32-bit support, mostly, because Xen
dropped it too. Maybe you can dig up these changes in the commit history.
In general, terms are 32-bit in LING and there must not be much needed to
run it on 32-bit OS. You can grep the code for int_ptr_t or sizeof(void *).
These are most likely culprits.
M
On Sun, Mar 26, 2017 at 2:17 AM, Stephane Bourque <notifications@github.com>
wrote:
… Fantastic Maxim!
Made the suggested change and all compiles. Railing works. The generated
image crashes during an assert() in proc_make line 61, ... core/proc.c The
image then freezes up...
Do you know if there is a reason or something would be limiting running
LING on 32 bit OS? Or compiled in 32 bit mode? I see a lot of casting to
(u_int32) and memory compares and for sure this would fail on 64 bit OS. Am
I out to lunch? Am I missing some flag when starting the image?
Thanks again...
On Sat, Mar 25, 2017 at 3:03 AM Maksym Kharchenko <
***@***.***>
wrote:
Stephane,
I have found a possible fix for you. See bc/ling_code.erl lines 90-91. It
converts reg 1023 (non-existent) to reg 255 (rarely used). It is a hack in
the same vein as reg 1023 is a hack. You can add another case to convert
reg 1022 to reg 254.
A few comments on how LING and BEAM differ:
1. Both LING and BEAM use the same high-level instruction set you can see
when you disassemble BEAM files. However, it is not the instruction set VMs
execute. They execute highly-optimized low-level instructions and these are
different between LING and BEAM. The low-level instruction set for LING is
bc/iops.tab.
2. BEAM translates from high-level to low-level instructions upon module
load. For this it uses a sophisticated engine similar to a Prolog
interpreter. LING does the translation statically upon compilation of the
module. .ling files contain low-level instructions. The goal of the
approach is to make LING start faster.
3. Both BEAM and LING use specialized 'variants' for low-level
instructions. For instance, there may be instruction variant to add a
register to reg0 and a more general variant to add two arbitrary registers.
The difference is that BEAM enumerates all instruction variants
statically. LING 'discovers' optimal instruction variants by collecting
statistics on a body of Erlang sources (stdlib). More variants allow the C
compiler produces a faster code, but at the same time increase the code
size of the interpreter. You can see discovered instruction variants in
bc/ling_iopvars.erl (after the build).
4. The main source of LING interpreter is core/ling_main.c. The file is
generated to accommodate for all instruction variants discovered earlier.
Regards,
M
On Sat, Mar 25, 2017 at 2:33 AM, Stephane Bourque <
***@***.***>
wrote:
> Thanks for looking into this Maxim.
>
> I am still interested. If you could point me in the right direction, I
> would love to investigate and see if I can address this issue.
>
> I assume I need to look for changes in Beam in R19 to previous revs. Are
> there some additional docs for Ling and how it differs from Beam?
>
> I appreciate any info..
> On Tue, Mar 21, 2017 at 19:08 Maksym Kharchenko <
***@***.***>
> wrote:
>
> > This is likely a change to the Erlang compiler introduced in R19.
> >
> > The compiler used to emit references to a 'temporary' registers, such
as
> > r1024 despite the fact that there are only 256 registers. Maybe, now
> > compiler emit references to more of such short-lived out-of-bound
> > registers.
> >
> > Anyways, the investigation and correction will take considerable time I
> do
> > not have now.
> >
> > Regards,
> > M
> >
> >
> > On Mon, Mar 20, 2017 at 6:16 AM, Stephane Bourque <
> > ***@***.***>
> > wrote:
> >
> > > @maximk <https://github.com/maximk> Thanks for helping...
> > >
> > > Here is the first significant warning
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *core/ling_main.c: In function ‘proc_main’: core/ling_main.c:5678:3:
> > > warning: array subscript is above array bounds [-Warray-bounds]
> rs[1022]
> > =
> > > *(term_t *)expand_ptr(tmp_arg1); ^ core/ling_main.c:5976:7: warning:
> > array
> > > subscript is above array bounds [-Warray-bounds] if (rs[1022] !=
> > > (term_t)ip[2]) ^*
> > >
> > > Now changing NUM_REGS to 1024 fixes the warning, but I see some
> > > significance to 1022.
> > >
> > > Here is the error when running railing image for cowboy's hello_world
> > > example.
> > >
> > > _Compile:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *rel/hello_world_example/lib/asn1-4.0.4/ebin/asn1ct_check.beam
> escript:
> > > exception error: no function clause matching
> > > ling_lib:enc({reg_as_term,1022}) (bc/ling_lib.erl, line 233) in
> function
> > > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in
call
> > from
> > > ling_lib:'-encode/1-lc$^0/1-0-'/1 (bc/ling_lib.erl, line 231) in
call
> > from
> > > ling_lib:encode/1 (bc/ling_lib.erl, line 231) in call from
> > > ling_lib:code_chunk/1 (bc/ling_lib.erl, line 174) in call from
> > > ling_lib:specs_to_binary/1 (bc/ling_lib.erl, line 125) in call from
> > > railing:compile/2 (railing/railing.erl, line 399) in call from
> > > railing:'-main/1-lc$^9/1-8-'/2 (railing/railing.erl, line 198)*
> > >
> > > This 1022 pops again. Happens wetter the NUM_REGS is set to 1024 too.
> > >
> > > I compiled LING with the latest build-essential, using Erlang V19.2
> > >
> > > I added a new BIF for erlang:timestamp() (I just duplicated what was
> > there
> > > for erlang:now() ).
> > >
> > > Let me know if you need anything else.
> > >
> > > Thanks
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > > Reply to this email directly, view it on GitHub
> > > <#141 (comment)
>,
> > or mute
> > > the thread
> > > <
> > https://github.com/notifications/unsubscribe-
> auth/AAEFTA0aJNG1PAhQG2ncGe_WjwrW9U7pks5rnf2HgaJpZM4ImGyY
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <#141 (comment)>,
> or mute
> > the thread
> > <https://github.com/notifications/unsubscribe-auth/
> ABxfxBljYA4K70vAJorykcvY14vgcm58ks5rn6-fgaJpZM4ImGyY>
> > .
>
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#141 (comment)>,
or
mute
> the thread
> <
https://github.com/notifications/unsubscribe-auth/
AAEFTOY5ys2v8B21MEzEQiQQk9M0ho_qks5rpGDxgaJpZM4ImGyY
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABxfxBjZo0MxWXvzmLBy_
HP5G_KHFH2Lks5rpOZVgaJpZM4ImGyY>
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAEFTMgBBHzFjFl90WAT_QxZgoLL5lkyks5rpa6GgaJpZM4ImGyY>
.
I made some progress towards enabling erlang 19.0. Now I crashed at: but at least otp is starting.
TRACEEX: caught [<0.10.0>] error:badarg stack [{maps,merge,[#cp,#err(0x1027e94e)],[]},{supervisor,check_flags,1,[{file,"supervisor.erl"},{line,1254}]},{supervisor,set_flags,2,[{file,"supervisor.erl
"},{line,1244}]},{supervisor,init,1,[{file,"supervisor.erl"},{line,296}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}
]
When you compile LING, do you get any warnings?
…On Sun, Oct 7, 2018 at 8:54 AM Howard Su ***@***.***> wrote:
I made some progress towards enabling erlang 19.0. Now I crashed at: but
at least otp is starting.
TRACEEX: caught [<0.10.0>] error:badarg stack
[{maps,merge,[#cp,#err(0x1027e94e)],[]},{supervisor,check_flags,1,[{file,"supervisor.erl"},{line,1254}]},{supervisor,set_flags,2,[{file,"supervisor.erl
"},{line,1244}]},{supervisor,init,1,[{file,"supervisor.erl"},{line,296}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}
]
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABxfxM65JY9doFMWVsXESIr5AuwEJxzcks5uiiOngaJpZM4ImGyY>
.
--
Stéphane Bourque
If it is pressing/important I can have a look into it. I will need sources with the latest changes.
check the source here:
https://github.com/howard0su/ling/tree/erlang19
It happens in decode_literals() in code_base.c.
…On Tue, Oct 9, 2018 at 11:41 AM Howard Su ***@***.***> wrote:
I narrow down the problem. Looks like a compile error.
the following beam
{move,{literal,#{intensity => 1,period => 5,strategy =>
one_for_one}},{x,0}},
is converted to a move_0 in LING.
however, i debug through ling_main.c in VM. the ip[1] is contain value
270613442, which is not a valid map but a float??
move_1: ATTRIBUTE_HOT
{
void *next = (void *)expand_ptr(ip[2]);
r0 = (term_t)(is_reg(ip[1]) ?(ip[1] == reg0) ?r0 :rs[reg_index(ip[1])]
:is_slot(ip[1]) ?sp[slot_index(ip[1])+1] :ip[1]);
^^^^^^^^^^^^^^^^^^^ip[1] == 270613442, after this instruction, r0 ==
270613442
ip += 2;
goto *next;
}
Where is the code load the literals and convert it into term or it is
converted already during compile LING time?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAEFTMzp_km3GudPfNadiPlGiNorm1btks5ujGFFgaJpZM4ImGyY>
.
I found the issue. the map implementation in ling is incomplete and buggy. in 17.0, there is almost no usage for map. but in 19.0, map is used for process state.
Please check my latest commit in my branch to see the code. code is quick code and I even use bubble sort.
Now I am facing another crash in execute instruction get_map_elements_0.
updates, after fixing all map related issue, the shell actual starts (still one more thing to go that there is no echo when typing.) but at least erlang VM starts well now.
This is true that the map implementation leaves much to be desired. It has not been in use much.
Yes. now it is used in many places of stdlib. Now I am porting over one change which cause no echo after started, erlang/otp@48083e5
finally, the console works. time to try. I don't have XEN box and I only tested posix ARCH.
Erlang [ling-0.5.0]
Eshell V6.3 (abort with ^G)
1> test:run(lists).
append_1 ok
append_2 ok
....
Total: 68, Ok: 68, Failed: 0
{68,0}
2> q().
ok
3> console_detach()
The homepage for this project is down. I'll have to assume the project is dead?
:'(
Is it project is down? I like help this amazing opensource project to continues. :(
yes, would be great to see this project continue, it has a lot of potential
not sure if Maksym is around to maintain this, further development and keeping up with Erlang updates requires a team so perhaps when there is a commercial demand and budget someone can fork this and continue hopefully keeping it open source