~duangle/scopes

2 2

unexpected behavior with arrays?

Details
Message ID
<CAAhSavZq+TFWtwg1+V_XC5W9cED8SFyzeqf1Na1LnzsePL5_XA@mail.gmail.com>
DKIM signature
missing
Download raw message
MINGW64 /g/Devel/scopes-repo/bin
$ ./scopes
  \\\
   \\\   Scopes 0.16 (Jul  3 2020, 22:39:29)
 ///\\\  http://scopes.rocks
///  \\\
$0 ► local y = 5
5
$0 ► let x = (alloca-array i32 y)
$imexebel:(mutable@ (storage = 'Function) i32)
$0 ► x @ 0 = 1
$0 ► x @ 1 = x @ 0 + 1
$0 ► x @ 2 = x @ 1 + 1
$0 ► x @ 3 = x @ 2 + 1
$0 ► x @ 4 = x @ 3 + 1
$0 ► assert ((x @ 4) == 5)
<string>:1:1: assertion failed: ((x @ 4) == 5)

Not sure what to make of this.

----------------------

MINGW64 /g/Devel/scopes-repo/bin
$ ./scopes
  \\\
   \\\   Scopes 0.16 (Jul  3 2020, 22:39:29)
 ///\\\  http://scopes.rocks
///  \\\
$0 ► local y = 5
5
$0 ► let x = (alloca-array i32 y)
$imexebel:(mutable@ (storage = 'Function) i32)
$0 ► x @ 0 = 1
$0 ► x @ 1 = x @ 0 + 1
$0 ► x @ 2 = x @ 1 + 1
$0 ► x @ 3 = x @ 2 + 1
$0 ► x @ 4 = x @ 3 + 1
$0 ► x @ 0
$0 = 0
$1 ► x @ 1
$1 = 0
$2 ► x @ 2
$2 = 0
$3 ► x @ 3
$3 = 0
$4 ► x @ 4
$4 = 0

----------------------------

Does anyone else see this behavior or is this issue specific to the
Windows build somehow?

-- 
Shawn Walker-Salas
Details
Message ID
<INGYCQ.3W7RABKQ2ZWQ@gmail.com>
In-Reply-To
<CAAhSavZq+TFWtwg1+V_XC5W9cED8SFyzeqf1Na1LnzsePL5_XA@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message

On Fri, Jul 3, 2020 at 22:45, Shawn Walker <binarycrusader@gmail.com> 
wrote:
> $0 ► x @ 0
> $0 = 0

TL;DR: you have a stale stack pointer.

As you probably know, `alloca`'d pointers are not meant to survive 
beyond the function frame, and the way the REPL works is that it wraps 
every evaluated expression in a function; the result of this is that 
it's impossible to keep function-local pointers valid between 
evaluations. What you may do is use a global array instead, or even one 
using the `local` keyword since that was improved recently to work 
better in this situation. Your code will work like this:

```
$0 ► local x : (array i32 5)
(arrayof i32 0 0 0 0 0)
$0 ► x @ 0 = 1
$0 ► x @ 1 = x @ 0 + 1
$0 ► x @ 0
$0 = 1
$1 ► x @ 1
$1 = 2
```

Westerbly (radgeRayden) Snaydley.
Details
Message ID
<CAAhSava+fbB9+a19p0MAxZj7kVYqSwV4v0OOVkcCCf=f9r+mzw@mail.gmail.com>
In-Reply-To
<INGYCQ.3W7RABKQ2ZWQ@gmail.com> (view parent)
DKIM signature
missing
Download raw message
[resending reply for list]

After sleep this is obvious in retrospect. Sorry for the noise.  The
missing piece was that I didn’t think of what scope the repl was
evaluating statements.

I had copied this from one of the tests and so was puzzled because I
hadn’t thought hard enough about scopes and the repl.

However, this does point out a possible nice usability enhancement for
the repl at least but maybe also the Scopes compiler?

I guess I’m spoiled by the rust compiler’s reasoning about lifetimes.
If I try to use ‘x’ once the binding has expired it won’t let me and
tells me why.  Here it seems like Scopes should know the lifetime of
the storage and then could prevent or warn about further use.

Thanks though for helping me stumble through this.

On Sat, 4 Jul 2020 at 10:31, Westerbly Snaydley <westerbly@gmail.com> wrote:
>
>
>
> On Fri, Jul 3, 2020 at 22:45, Shawn Walker <binarycrusader@gmail.com>
> wrote:
> > $0 ► x @ 0
> > $0 = 0
>
> TL;DR: you have a stale stack pointer.
>
> As you probably know, `alloca`'d pointers are not meant to survive
> beyond the function frame, and the way the REPL works is that it wraps
> every evaluated expression in a function; the result of this is that
> it's impossible to keep function-local pointers valid between
> evaluations. What you may do is use a global array instead, or even one
> using the `local` keyword since that was improved recently to work
> better in this situation. Your code will work like this:
>
> ```
> $0 ► local x : (array i32 5)
> (arrayof i32 0 0 0 0 0)
> $0 ► x @ 0 = 1
> $0 ► x @ 1 = x @ 0 + 1
> $0 ► x @ 0
> $0 = 1
> $1 ► x @ 1
> $1 = 2
> ```
>
> Westerbly (radgeRayden) Snaydley.
>
>


-- 
Shawn Walker-Salas
Reply to thread Export thread (mbox)