I try to use across 1|..|list.count as j all list.i_th(z) ~ old list.i_th(z) end

but it says unknown identifier z. Whats wrong with this syntax??

I have found one case that does not make sense.

I have following feature:

test_array_deep_copy: BOOLEAN
        local
            imp, old_imp: ARRAY[STRING]
        do
            comment("Test of a deep copy.")
            create {ARRAY[STRING]} imp.make_empty
            imp.force ("Alan", 1)
            imp.force ("Mark", 2)
            imp.force ("Tom", 3)

            old_imp := imp.deep_twin
            imp[2] := "Jim"

            Result :=
                across
                    1 |..| imp.count as j
                all
                    j.item /= 2 implies imp [j.item] = old_imp [j.item]
                end
            check not Result end
        end

Since it is deep copy, that means address of imp and old_imp are different, as well as that its attributes in both two also refers to different address.

So, this "Result" after across loop, it should be false because addresses in imp and old_imp at same index are different.

So when I debug this code, it say Result is set to be false after finishing across loop.

The problem is that "check not Result" does not make false to true.

If I run workbench system, it says following:

I do not know why. "not" before "Result" in "check not Result" statement should make its whole check true, so it should say "PASSED" in workbench system, but it fails.

why is that?

On Mon, 2017-10-09 at 15:14 +0300, 'Alexander Kogtenkov' via Eiffel Users wrote: > The action agent is passed additional arguments that the current > version of the procedure on_make_extra does not handle. The solution > is to change the signature of the feature to > > on_make_extra (data:

The action agent is passed additional arguments that the current version of the procedure on_make_extra does not handle. The solution is to change the signature of the feature to on_make_extra (data: DATA; x, y: INTEGER_32; button: INTEGER_32; x_tilt, y_tilt: REAL_64; pressure: REAL_64;

I have just come back to a project after a year and a couple of upgrades of Eiffel. Some code that used to compile now will not do so. pds_make_pd_row (...) local ... eic: EV_GRID_CHOICE_ITEM do

I love my Samsung Galaxy Tab S2. It's light enough that I never notice it in my back pack and has everything I need for being out and about. For this reason I have no desire to own a laptop. If I am on holiday I bring a small bluetooth keyboard with me and then it functions as a laptop. However

Hi Alexander, yes it would be interesting, but I don't expect there will be much difference unless you are distributing very many small tasks across a pool of threads, in which case I suspect SCOOP will be faster. Would you be interested to implement the class EL_WORK_DISTRIBUTER using SCOOP and

I found one such resource although it doesn't answer all my questions http://ithare.com/infographics-operation-costs-in-cpu-clock-cycles/ but in any event I solved my problem by trial and error. feature -- Basic operations resume -- unblock thread do can_resume

The description for this routine is: -- Block calling thread on current condition variable for at most `a_timeout' milliseconds. -- Return `True' is we got the condition variable on time, otherwise return `False' I interpreted the return value statement to mean that it returns true if a signal

I have no answers to your questions. However, it would be interesting to benchmark your implementation against the current SCOOP implementation that utilizes lock-free queues, automatically avoids context switching when separate calls are synchronous, relies on event notification rather than

I am close to perfecting a multi-threading work distribution class and to fine tune the synchronization of events I need to know the relative execution time of various operations. I remember once finding a useful page of information that gave ballpark figures for basic C operations like:

Hi Jocelyn Thank you so much Philippe Le mercredi 4 octobre 2017 17:42:17 UTC+2, Jocelyn Fiat a écrit : > > Hi Philippe, > > The example is working fine, but it assumes the source code is ASCII text > and not unicode. > However in your code, you use the unicode quote in "user’s" instead of >

Hi Philippe, The example is working fine, but it assumes the source code is ASCII text and not unicode. However in your code, you use the unicode quote in "user’s" instead of "user's" (hard to see). So probably the example could be improved to reject any unicode source code, or to handle

Dear list members, it's "Hacktober" again https://hacktoberfest.digitalocean.com/ and there are currently no issues on Github-hosted Eiffel projects marked as suggested for new contributors with the "Hacktoberfest" tag https://github.com/search?q=label:hacktoberfest+state:open+type:issue Maybe

in Eiffel this would be the same as firstName: detachable STRING That would seem to imply that all variables are attached by default in Kotlin. So what happens if you declare var firstName: String and then never initialize it. Does it call implicitly a default creation routine? Or does the

I think this code snippet would be a test example, if you do not assign "Adam" in the first place: fun main(args : Array) { val firstName : String = "Adam" val name : String? = firstName print("$name") } I can try out, on the weekend, if the compiler gives an error or

I have followed some discussion of Kotlin language, where they describe the nullable type with an appended question mark: ###Null In Kotlin you have to decide whether a variable can be assigned null or not. This applies to both primitives or class types. A nullable variable is marked

Kotlin does require that all fields of non-null types are initialized. However, it does not prevent from using a reference to the current object before all fields are initialized. As a result, one can easily get a NullPointerException in pure Kotlin. In other words, its null-safety is unsound:

Yes, at work we are still in the non-void-safe part of the world, and we use the Gobo libraries without any problems. -- Eric Bezault mailto:er...@gobosoft.com http://www.gobosoft.com

I think that the ECMA standard accepts STRING in addition to INTEGER and CHARACTER. > The first thing to notice is that there is no temporary renaming using > the `as' keyword, because we have effectively defined a scope starting > from "when attached then" until the matching `else', in which

Hi Eric, thanks for sharing your experience on this matter. I browsed through some of the latest Gobo code to see what kind of changes (and how frequent) you had to make. It doesn't seem that bad. Since (correct me if I am wrong) void-safe libraries can be used in none-void safe ones then

Just to give some quantitative data, the library Vision required 1.1% of code changes to go from completely void-unsafe to transitionally void-safe. This includes added/removed/modified lines of code. To go from transitional to completely void-safe, the same metric raised to 11.7%. So, the total

Come to think of it, since "if then" conditionals are not required to have `else' keyword, we could make the closing `else' optional for this alternate use of `inspect' as well. So our example code would look like this: on_mouse_move (a_x, a_y: INTEGER; a_x_tilt, a_y_tilt, a_pressure: DOUBLE;

Not worth a new keyword IMHO. On Sun, 1 Oct 2017 at 15:25 Finnian Reilly wrote: > I offer this suggestion for some future version of the Eiffel language > that I think would make void-safe coding constructs clearer. It involves > creating an additional use for the `inspect-wh

The basic idea is not dependent on having any new keywords. If most people don't like `detached' we can make do with "when not attached", but as Eiffel already has so many keywords, we may as well be "hung for a sheep as a lamb" as the saying goes.