objectionary / eo-threads Goto Github PK

The puzzle 33-016de260 from #33 has to be resolved:

The puzzle was created by @levBagryansky on 01-Oct-22.

Estimate: 90 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

The puzzle 33-5c60b9c8 from #33 has to be resolved:

The puzzle was created by @levBagryansky on 01-Oct-22.

Estimate: 90 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

The puzzle 12-c377ed5d from #12 has to be resolved:

The puzzle was created by @levBagryansky on 15-Sep-22.

Estimate: 90 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

@yegor256 I think it would be better if thread.join throw exception if slow is not computed. Now if smth goes wrong in dataization we get NullPointerException I think it is better to throw ExFailure in this case.

Does EO thread management supports the Green threads (like Kotlin coroutines)?

It seems I cannot yet implement thread.stop.
This is implementation of run in DataizingThread.java:

    public Phi dataized() {
        return this.computed;
    }

    @Override
    public void run() {
        this.computed = new Data.ToPhi(new Dataized(this.eothread.attr("slow").get()).take());
    }

And stop in its dataization will do

      final Phi parent = rho.attr("ρ").get();
      final DataizingThread thr = Threads.INSTANCE.get(parent);
      thr.interrupt();
      return new Data.ToPhi(true);

So in DataizingThread.java it must be

    @Override
    public void run() {
        try {
            this.computed = new Data.ToPhi(new Dataized(this.eothread.attr("slow").get()).take());
        } catch (InterruptedException ie){
        }
    }

But compiler does not allow do that because
Exception 'java.lang.InterruptedException' is never thrown in the corresponding try block
So Dataized.get does not throw it. But Thread.sleep that is used in EOsleep.java can do.
@yegor256 @mximp may be we have other ways to stop the thread? I see only bad variants like deprecated Thread.stop and may be JNI. Or we need to mark some nethods in eo throws InterruptedException?

#93 Fails because memory object was changed, we need to edit usage of memory.

@yegor256 stress-test in #59 failed. I think it is better to disable the test and create more tests in java which would simulate the eo code.

We need to add tests for thread using threads.sleap and QQ.sys.call "gettimeofday" when it wiill be released

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update junit5 monorepo to v5.10.3 (org.junit.jupiter:junit-jupiter-params, org.junit.jupiter:junit-jupiter-api)
• Update dependency com.jcabi:parent to v0.68.0
• Update dependency org.apache.maven.plugins:maven-compiler-plugin to v3.13.0
• Update eolang.version to v0.39.0 (org.eolang:eo-maven-plugin, org.eolang:eo-runtime)
• Update actions/cache action to v4
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

The puzzle 61-0d624b73 from #61 has to be resolved:

The puzzle was created by @levBagryansky on 16-Oct-22.

Estimate: 90 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

Let's implement QQ.threads.sleep according to #9 " which makes dataization pause for the given amount of milliseconds"

We need to change return value of thread.start.

To be sure thread dataizes it's argument slow after start we can implement time and sleep objects that helps to regulate dataization time sleep does it) and measure (time does it) :
[millis] > sleep stops dataization for millis milliseconds
[] > time is an analog of System.currentTimeMillis() in java.
So we can write

[] > test-it-dataizes-after-start
  thread > a
    sleep 3000
  thread > b
    sleep 3000
  memory 0 > m1
  memory 0 > m2
  seq > @
    m1.write
      time
    a.start
    b.start
    a.join
    b.join
    m2.write
      time
    gt.
      4000
      minus.
        m1
        m2

Here we can be sure a and b works in parallel.
@yegor256 @mximp What do you think?

Let's configure Rultor the same way it's done in eo-files, and release the first version to Maven Central

We need to increase stack size up to 256 mb

@rultor hello

@yegor256 last time we decided mutex should look like this:

[permits] > mutex
  [] > acquire
    [] > @ /bool
    [] > release /bool

to use the mutex the way:

[] > acquire-release
  mutex 100 > m
  seq > @
    m.acquire > a
    a.release
    m.acquire > b
    b.release

But it makes us to copy mutex.acquire if we want to distinguish a and b. In fact it would be better adding ':

[] > acquire-release
  mutex 100 > m
  seq > @
    m.acquire' > a
    a.release
    m.acquire' > b
    b.release

And here I faced this issue:
objectionary/eo#1214

As per changes in objectionary/eo#1869 for all EO tests replace +junit with +tests.

In my opinion, this would be more convinient to call the base package QQ.concurrent (or QQ.concurrency) rather than QQ.threads.

Looks like a typo: used t instead of x to reference the thread object in README (at line 20)

QQ.threads.thread > x
  [t]
    very-slow-object > @
while.
  t.is-running
...

The puzzle 14-d4ce4bb2 from #14 has to be resolved:

The puzzle was created by @rultor on 08-Sep-22.

Estimate: 90 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

See how it's done in eo-collections or eo-files

@yegor256 let's implement is-running according to readme:

is-running is TRUE if it is still working

Please assign me

@mximp
Please rate my suggestion. I came with 2 usage of threads.

1. Its enough ordinary usage. You just run the thread and can use several attributes to get its state: join, is-alive, etc .

[] > usage1
  QQ.threads.thread > my-thread
    slow-obj
  seq > @
    run.
      my-thread
    do-smth
    join.
      my-thread

2. The fist usage may have too imperative style. So its alternative. You can declarative some threads in one place and run it where you need. It will return true after finish.

 [] > usage2
  QQ.threads.thread-set > my-thread-set
    slow-obj1
    slow-obj2
    slow-obj3
  run. > @
    my-thread-set

We need to set valid metas in all eo-files.
@yegor256 I would like to do it in separate pull request

PR #99 fails due to using of /? outside of org.objectionary package. eolang.version needs to be updated manualy.

It doesn't say anything about join, for example.

The puzzle 33-42a5749e from #33 has to be resolved:

The puzzle was created by @levBagryansky on 01-Oct-22.

Estimate: 90 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

See how it's done in eo-files or eo-collections. We should do the same here, with a badge

@yegor256 Let's implement mutex object. It will have mutex.lock and mutex.unlock attributes so only one thread can own the mutex in a moment.

The puzzle 12-aaf1d833 from #12 has to be resolved:

The puzzle was created by @levBagryansky on 15-Sep-22.

Estimate: 90 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

PR #87 does not pass because PhDefault.hashcode() method was reimplemented in new version of eo (objectionary/eo#2157). We need to remove redundant wrong test https://github.com/objectionary/eo-threads/blob/master/src/test/java/EOorg/EOeolang/EOthreads/EOmutexTest.java#L72 or change it for reimplemented PhDefault.equals() method.

The puzzle 14-371bfc16 from #14 has to be resolved:

The puzzle was created by @levBagryansky on 25-Sep-22.

Estimate: 60 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.