larger delay for GitHub calls in cucumber tests

@rultor release, tag is 0.0.38

@rultor release, tag is 0.0.38

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.0.38

@yegor256 Done! FYI, the full log is here (took me 9min)


docs(components): update to use ionicons v5

Pull request checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[x] Build (npm run build) was run locally and any changes were pushed
[ ] Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[x] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Updates our tests & usage to reflect Ionicons v5
Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

I spoke with Kevin about the ellipsis not being filled, see: https://codepen.io/brandyscarney/pen/xxbPOVm?editors=1100
He is going to fix it in the source. We can wait for a new ionicons for this.

This is good to go now, using latest ionicons, cc @liamdebeasi


Use globalThis for next version

It's too late to land this in v7, IMO... but I think we should move to using globalThis in our next major, instead of that silly root module we have now. It would require a polyfill for IE.

:+1: from core team meeting.


Bevy 0.15

Pretty straight forward upgrade. Notable changes that impact this project are:

Handle is not a component anymore so I needed to introduce wrapper components
Have to use RenderEntity in extaction now
RenderVisibleEntities to get visible RenderEntitiy MainEntity pairs
Examples now all use required component approach instead of bundles

Everything seems to work but I tried to keep the effort as small as possible.
Should probably migrate to required components instead of bundles.
Let me know if you would like any changes :)

I have no authority on the topic but it would be easier to use if the API mimics Mesh3d and Mesh3dMaterial:
#[require(Transform, Visibility)]
pub struct Mesh3d(pub Handle<Mesh>);

So just PolylineHandle would require Transform and Visibility which would produce GlobalTransform, InheritedVisibility and ViewVisibility.
Mesh3d does not require Mesh3dMaterials but won't render unless it has a material, so that's probably what PolylineMaterialHandle should copy.

I have no authority on the topic but it would be easier to use if the API mimics Mesh3d and Mesh3dMaterial:
#[require(Transform, Visibility)]
pub struct Mesh3d(pub Handle<Mesh>);

So just PolylineHandle would require Transform and Visibility which would produce GlobalTransform, InheritedVisibility and ViewVisibility.
Mesh3d does not require Mesh3dMaterials but won't render unless it has a material, so that's probably what PolylineMaterialHandle should copy.

I agree but I wanted to keep the changes as minimal as possible because I don't know if the authors might want to keep the bundle worklfow. Happy to implement the required component approach once I know if it is preferred.


how to bind a complex list

Model Binding in ASP.NET Core is complex . I do not know how to  invoke a get/post webapi that contain a complex type collection,
for example:
string Add( List<Apple> apples).

OR :
class Apple{public string Name;}     class Pear {public string Name;}

string Merge( Apple apple,Pear pear  );

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e24f48f8-6c4d-ecda-6ce6-a7826d396e99
Version Independent ID: 9c4af557-8d06-4c6c-ad2a-0dd234547563
Content: Model Binding in ASP.NET Core
Content Source: aspnetcore/mvc/models/model-binding.md
Product: aspnet-core
Technology: aspnetcore-mvc
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Take a look at [Binding Complex Collections link]{https://www.learnrazorpages.com/razor-pages/model-binding#binding-complex-collections)
cc @serpent5

@Rick-Anderson  Thanks!


The purpose of Model-7B-stage1 and Model-13B-stage1, and how to use it?

Model-7B-stage1 and Model-13B-stage1 have not been instruct-tuned and are suitable for those needing to fine-tune their own data.


[vtk-hdf] test more features

Some of the features are currently not tested:

cell data for vtk-hdf-image-data
regression-testing of vtk-hdf transient files

Once vtk 9.2.7 is out, which should contain the respective fixes/features, we should add this to the test suite.

Edit: with #199 we modified the exit code computation in the regression test script. It used to take the max of all return codes, however, it seemed that when reading vtk-hdf image grid files, a return code of -6 was discarded with this and the test passed although an invalid pointer free operation occurs. This is due to a bug in the reader, which has already been fixed in VTK.
As with many other hdf-related features, we have to wait until the 9.2.7 release of VTK. Until now, all vtk-hdf-image grid regression tests are deactivated.


What is this sorcery

Dayum... How does this work ?

Glad you like it. I am misusing an http connection and piping the output of the real asciiquarium into the session without closing it.
It's not my idea, there are similar projects doing that for years. See the readme.


LEGO: Pull request from lego/hb_04604851-bac4-4681-9f74-73de611d6e48_20210804153302598 to main

LEGO: Pull request from lego/hb_04604851-bac4-4681-9f74-73de611d6e48_20210804153302598 to main with localized lcls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 41.473%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
26236

Relevant Lines:
57354

💛  - Coveralls


"Join Game" popup displays shadow of "Create New Game" popup

After clicking "Create New Game" and then "Join Game", the "Join Game" text unintentionally serves as an overlay for "Create New Game". Possibly both are being displayed or one is still shown.

fixed in branch web


Pull LUDOX protocol out of tests.

Preparation
Take the building of the LUDOX protocol object and file out of the body of the test, and move it to a python script in the examples/ directory.  The test now will load and run this procedure, making it reusable.
The top level ludox_protocol procedure is decomposed into sub-procedures, to make it possible to demonstrate it step-by-step, the way @dbryce has done in his jupyter notebook.
Data model revision
Replace the existing use of an SBOL Identified object for the container specification with a string. This seems to be the only practical way of allowing the container specification to be an OWL expression.  Long discussions with OWL experts suggest that RDF is a poor storage medium for expressions (except as strings).
Incidental repair
One of my specification strings blew up the translation to dot (graphviz): needed to ensure that label strings are HTML escaped in the translation process.
Remaining
Tests need repair.

Hello,
you keep mentioning me (username @dbryce) in this thread but you have
the wrong user. Please check the username of the 'd bryce' you are
trying to make contact with!
Best,
Donna Bryce
Am 04.10.2021 um 18:23 schrieb rpgoldman:

Take the building of the LUDOX protocol object and file out of the
body of the test, and move it to a python script in the examples/
directory. The test now will load and run this procedure, making it
reusable.
The top level |ludox_protocol| procedure is decomposed into
sub-procedures, to make it possible to demonstrate it step-by-step,
the way @dbryce https://github.com/dbryce has done in his jupyter
notebook.

    You can view, comment on, or merge this pull request online at:

https://github.com/SD2E/paml/pull/51
https://github.com/SD2E/paml/pull/51
    Commit Summary

Pull LUDOX protocol out of tests.
https://github.com/SD2E/paml/pull/51/commits/e492dd0b2873c2ac6557626eae7d119d834dd4df

Change type of EmptyContainer specification
https://github.com/SD2E/paml/pull/51/commits/003e30a9e0bffec56c53984e3659f8bbb3d03c20

Fix HTML bug in protocol to dot translation.
https://github.com/SD2E/paml/pull/51/commits/7c011ea70f6eb7c1c933a0d6e561e650a5902025

LUDOX protocol with new specification.
https://github.com/SD2E/paml/pull/51/commits/9596a35b908e1fefb48fa8962941040e3534eba1
File Changes

A examples/LUDOX_protocol.py
https://github.com/SD2E/paml/pull/51/files#diff-82b31136d7ab5f1d35d4c6da4de5c6aebc1dd2ba8f948d8d75d0a9d45b995407
(163)

M paml/init.py
https://github.com/SD2E/paml/pull/51/files#diff-9c03701d8e48c4ce59aed42a01b2ccc1cac80b622219b75f1d870562b6106ed6
(6)

M paml/lib/sample_arrays.ttl
https://github.com/SD2E/paml/pull/51/files#diff-50ec9de0a9fe89d588b6ff8d6fd529ce19cabea015d499d4c13857a228d2a3ae
(2)

M test/test_LUDOX_protocol.py
https://github.com/SD2E/paml/pull/51/files#diff-aba723f25df332acd8deffc70a8ded5fabe286a6d47c238a8f0c334f94f7500c
(94)
Patch Links:

https://github.com/SD2E/paml/pull/51.patch
https://github.com/SD2E/paml/pull/51.patch

https://github.com/SD2E/paml/pull/51.diff
https://github.com/SD2E/paml/pull/51.diff

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SD2E/paml/pull/51, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASQTWNNUGNP6U6T6T4JILRTUFHIGTANCNFSM5FJYIBPA.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Dr. Donna Bryce
Margarete von Wrangell Fellow
Junior Group Leader: Cognitive Development
Eberhard Karls Universität Tübingen
Department of Psychology
Schleichstrasse 4 · 72076 Tübingen · Germany
Tel +49 7071 29-76763 · @.***
While I may email outside normal working hours, I do not expect a response outside your own.

@dbryce -- Sorry! Should be fixed now.

Force pushed a few tidying changes.

What's the protocol for merges? Always squash? a standard merge? or rebase?

A standard merge has always been my SOP.  Anything more fancy than that, and I'm likely to screw things up.


[Issue] Neruina taking noticeable amounts of tick time process entities

I don't know why Neruina lags my client this much. I know it has to check for erroring entities all the time and it can and will cause lag, but I'm not going to just give out 14% of my client's performance to just prevent a crash which will probably not even happen often.
I'll test an alternative erroring entity removal mod and see how much that lags my game.  The usage between Neruina method calls and vanillas tick calls is less than 0.01%.
Neruina wraps vanilla tick calls, it doesn't check every tick, it just catches any errors thrown during the ticking process. I literally called the method "notTheCauseOfTickLag" and put a notice on the mod page. Please learn how to read spark reports accurately, the raw percent values are not the only metric to look at, look at the self-time metrics as well.


Plug and play support for input devices

Hi
Version

Python: 2.7
OS: Raspbian Strech 9
Kivy: 1.10
Kivy installation method: pip

Description
I have a KIVY app which requires barcode scanners, NFC card scanners, keyboards, mouse to be disconnected and connected  back while the app is running.
However, kivy initialises all input devices during startup and does not seem to support plug and play for input devices.
Is this a limitation of Kivy or is there a workaround available for this?

This is a limitation, maybe somebody did a workaround for that, but our code doesn't support it.
You could be able to rescan somehow the devices and see if there is a new one.

That can probably be done by monitoring the devices using 'udevadm monitor' and removing and adding then from/to EventLoop as needed.
There's another related issue that i am facing. Reconnecting the same device back throws the below exception:
##when disconnected
 Exception in thread Thread-10:
 Traceback (most recent call last):
   File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
     self.run()
[INFO   ] [MTD         ] </dev/input/event2> input device disconnected
   File "/usr/lib/python2.7/threading.py", line 754, in run
     self.__target(*self.__args, **self.__kwargs)
   File "/usr/local/lib/python2.7/dist-packages/kivy/input/providers/hidinput.py", line 686, in _thread_run
     data = fd.read(struct_input_event_sz)
 IOError: [Errno 19] No such device

##when connected back
 Exception in thread Thread-5:
 Traceback (most recent call last):
   File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
     self.run()
   File "/usr/lib/python2.7/threading.py", line 754, in run
     self.__target(*self.__args, **self.__kwargs)
   File "/usr/local/lib/python2.7/dist-packages/kivy/input/providers/mtdev.py", line 290, in _thread_run
     _device = Device(_fn)
   File "/usr/local/lib/python2.7/dist-packages/kivy/lib/mtdev.py", line 143, in __init__
     self._fd = os.open(filename, os.O_NONBLOCK | os.O_RDONLY)
 OSError: [Errno 13] Permission denied: '/dev/input/event2'

Sometimes, instead of 'No such device' I get the below exception when the device is disconnected:
Logger.info('MTD: <%s> input device disconnected' % _fn)

Could be similar to Issue #6141

in our case (Kivy-1.11.1, with provider=mtdev ), this patch for kivy/input/providers/mtdev.py allows the reconnection:
291c291,300
<                     _device = Device(_fn)
---
>
>                     while True:
>                         try:
>                             _device = Device(_fn)
>                         except PermissionError:
>                             Logger.info('MTD: <%s> permission error' % _fn)
>                             time.sleep(0.5)
>                         else:
>                             break
>

Of course,  a more robust solution would be to re-scan because the device might connect in another node... :shrug:

The first one (232, first initialization): leave it as it is.
The second one (290, reconnection attempt) is the one you should patch...

Perfect, thank you. It is also working for kivy 2.0.0dev0 with python 3.5.3 on raspbian 9 (Stretch)

I'm also having this error with this simple "hello world" example and Kivy 2.1.0, Python 3.10.4 and Tumbleweed 20220303.
`import kivy
from kivy.app import App
from kivy.uix.label import Label
Replace this with your
current version
kivy.require('1.11.1')
Defining a class
class MyFirstKivyApp(App):
# Function that returns
# the root widget
def build(self):

	# Label with text Hello World is
	# returned as root widget
	return Label(text ="Hello World !")

Here our class is initialized
and its run() method is called.
This initializes and starts
our Kivy application.
MyFirstKivyApp().run()
`

python3.10 kivyhelloworld.py
[INFO   ] [Logger      ] Record log in /home/myuser/.kivy/logs/kivy_22-04-09_16.txt
[INFO   ] [Kivy        ] v2.1.0
[INFO   ] [Kivy        ] Installed at "/usr/lib64/python3.10/site-packages/kivy/__init__.py"
[INFO   ] [Python      ] v3.10.4 (main, Mar 26 2022, 21:00:27) [GCC]
[INFO   ] [Python      ] Interpreter at "/usr/bin/python3.10"
[INFO   ] [Logger      ] Purge log fired. Processing...
[INFO   ] [Logger      ] Purge finished!
[INFO   ] [Factory     ] 189 symbols loaded
[INFO   ] [Image       ] Providers: img_tex, img_dds, img_sdl2, img_pil (img_ffpyplayer ignored)
[INFO   ] [Text        ] Provider: sdl2(['text_pango'] ignored)
[INFO   ] [Window      ] Provider: sdl2
[INFO   ] [GL          ] Using the "OpenGL" graphics system
[INFO   ] [GL          ] Backend used <sdl2>
[INFO   ] [GL          ] OpenGL version <b'3.0 Mesa 21.3.7'>
[INFO   ] [GL          ] OpenGL vendor <b'Intel Open Source Technology Center'>
[INFO   ] [GL          ] OpenGL renderer <b'Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2)'>
[INFO   ] [GL          ] OpenGL parsed version: 3, 0
[INFO   ] [GL          ] Shading version <b'1.30'>
[INFO   ] [GL          ] Texture max size <16384>
[INFO   ] [GL          ] Texture max units <16>
[INFO   ] [Window      ] auto add sdl2 input provider
[INFO   ] [Window      ] virtual keyboard not allowed, single mode, not docked
[INFO   ] [ProbeSysfs  ] device match: /dev/input/event2
[INFO   ] [MTD         ] Read event from </dev/input/event2>
[INFO   ] [Base        ] Start application main loop
[INFO   ] [GL          ] NPOT texture support is available
[WARNING] [MTD         ] Unable to open device "/dev/input/event2". Please ensure you have the appropriate permissions.


Break up load.py

It's a bit monstrous at the moment.

(Happy to take this on as part of the public-facing example usage effort)

Sure, let us know when you're actually moving all the code around so that we can try to avoid crazy merge conflicts.

I think a good first step would be moving Patient-related functions into the Patient object and out of the Cohort object. Then, Patient can be moved to patient.py. Caching logic should probably end up in a cache.py, though I think separate PRs for each step would be best.

@tavinathanson more to do here after #138? Maybe open an issue with more specifics now that load.py is gone?

I'm okay to close this for now.


Added docker, compose and volumes for easy local hosting on any machine

I have a portainer server for local hosting apps. I though that this would be a good inclusion so i could manage and easily update and deploy it when ever i want. (easy monitoring too). If you do accept this pull request then you would have to change the     image: ghcr.io/zippy-boy/wire-pod:main in the docker compose.yaml file to have your github name instead of mine, but that's all you would need to do. Thanks for reading though :)

Made an error. Fixed, new pull request


Synchronize for-ctl with master

last commit (cb66c2c) doesn't build

^ at least with cabal. it builds with nix build


NullPointerException - Sign In With Email - Firebase-UI-Auth 1.2.0

Hello,
Just came across with this problem and cannot overcome. I am getting a NullPointer when Signing In With Email, however the problem just happens in release mode and using proguard.
Please, find below the stack. Also opened a thread in here
https://stackoverflow.com/questions/44295185/nullpointerexception-sign-in-with-email-firebase-ui-auth-1-2-0?noredirect=1#comment75598983_44295185
java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.Context android.content.Context.getApplicationContext()' on a null object reference                                                    at com.firebase.ui.auth.util.signincontainer.SaveSmartLock.saveCredentialsOrFinish(Unknown Source)                                                    at com.firebase.ui.auth.ui.BaseHelper.saveCredentialsOrFinish(Unknown Source)                                                    at com.firebase.ui.auth.ui.email.RegisterEmailFragment$4$1.onComplete(Unknown Source)                                                    at com.google.android.gms.c.l$1.run(Unknown Source)                                                    at android.os.Handler.handleCallback(Handler.java:751)                                                    at android.os.Handler.dispatchMessage(Handler.java:95)                                                    at android.os.Looper.loop(Looper.java:154)                                                    at android.app.ActivityThread.main(ActivityThread.java:6123)                                                    at java.lang.reflect.Method.invoke(Native Method)                                                    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)                                                    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757)

See my response, this is fixed in v2.0 which will be available soon.

Can't wait @SUPERCILEX . Thanks for getting back so quickly! Closing the issue.

I have the same bug now

@clamentsanz please file a new issue if you're seeing this in a recent version


descriptor class for com.google.android.gms.vision.dynamite not found.

Log cat shows

Selected remote version of com.google.android.gms.vision.dynamite, version >= 801
com.google.android.gms.samples.vision.face.facetracker W/DynamiteModule: Local module descriptor class for com.google.android.gms.vision.dynamite not found.

build.gradle file as below
android {
compileSdkVersion 24
buildToolsVersion "24.0.2"
defaultConfig {
    applicationId "com.google.android.gms.samples.vision.face.facetracker"
    minSdkVersion 9
    targetSdkVersion 24
    versionCode 1
    versionName "1.0"
}
buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:support-v4:24.2.0'
compile 'com.android.support:design:24.2.0'
compile 'com.google.android.gms:play-services-vision:9.8.0'
}

Having same issue #154 in play-services-vision 10.0.0

Added full adb logs to #154 .

Same fail with sample application, log in #154.

Seems like it happens when we have pending downloads on google play.

@androidroadies Having the same issue. Did you find any solution?

@kevalpatel2106 Still not, I think it's a Play service issue so, wait.

I had this same log when I had low storage space.

Any solutions?

i have the same fail. but Establishing an internet connection successfully solved my problem.


Metalness implementation seems incorrect

TODO

[ ] Check existing function correctness
[ ] Compare against existing implementations
[ ] Understand why roughness grows so quickly
[ ] Non metal has no specular
[ ] Squaring the roughness improves comparison
[x] ~Ensure textures are in correct color space~

See straps that should be dark gray and yellow (and for some reason have a high metalness value)

Is possible this is a normal map / texture wrapping issue? Are UVs within [0, 1]?

This can somewhat be emulated with the material ball when setting the color to be fairly dark, roughness high, and then ramping the metalness up and down. It seems to get really bright in the metalness mid range and entirely dark at the ends. Perhaps theres an issue with the GGX functions?

Related: #221

See metalness (or maybe just glossiness) issues in the metal spheres comparison:

Squaring the roughness improves the falloff and make it look closer to the comparison though the "smoothest" setting still has low relflection. Metal may be the same. Perhaps the textures are being read in the wrong color space? Or are stored in the wrong color space?

Glancing fresnel looks incorrect:

Closing in favor of #264

Aviation Helmet after #315:

And Specular Test from Model Viewer:


Why was Builder().textLength() removed in 1.0.3

the readme has the following snippet:
val anotherReadMore: AnotherReadMore = AnotherReadMore.Builder(this)
    .textLength(100, AnotherReadMore.TYPE_LINE)
    .moreLabel("mais")
    .lessLabel("menos")
    .build()

but I see that the textLength method has been removed in v1.0.3. Any particular reason for that? Or is there an alternative method to set the max lines?

Sorry, I was refactoring the library code and I must have removed it without seeing it, I will release a new version with the indication of ownership again.

Thank you

implemented in version 1.0.6


The training job is stuck because the rpc server is not started in the evaluator

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): centos 7
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 2.4
Python version: 3.6
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

Describe the current behavior
tf version: 2.4
cluster spec:
{
    "ps":[
        "localhost:13344"
    ],
    "chief":[
        "localhost:15881"
    ],
    "worker":[
        "localhost:37309",
        "localhost:30812"
    ],
    "evaluator":[
        "localhost:22944"
    ]
}

example code:
def main(argv):
    cluster_resolver = tf.distribute.cluster_resolver.TFConfigClusterResolver()
    if cluster_resolver.task_type in ('ps', 'worker'):
        logging.info("[{}] Start {}({})...".format(get_cur_time(), cluster_resolver.task_type, cluster_resolver.task_id))
        server = tf.distribute.Server(
            cluster_resolver.cluster_spec(),
            job_name=cluster_resolver.task_type,
            task_index=cluster_resolver.task_id,
            protocol=cluster_resolver.rpc_layer or "grpc",
            start=True)
        server.join()

    if cluster_resolver.task_type == 'evaluator':
        ...
        checkpoint = tf.train.Checkpoint(model=model)
        ...

    if cluster_resolver.task_type == 'chief':
        logging.info("[{}] Start {}({})...".format(get_cur_time(), cluster_resolver.task_type, cluster_resolver.task_id))

        variable_partitioner = (
            tf.distribute.experimental.partitioners.FixedShardsPartitioner(
                num_shards=NUM_PS))

        strategy = tf.distribute.experimental.ParameterServerStrategy(
            cluster_resolver,
            variable_partitioner=variable_partitioner)

        ...

When i run tensorflow2.4 job with Custom Training Loop using ParameterServerStrategy on Yarn and use the same cluster spec on every process, it is stucked.
Finally, I found that the GRPC Server was not started by the evaluator process, which caused the coordinator to wait all the time.
Describe the expected behavior
According to the problem described above, there are two solutions：

in evaluator process, it start the grpc server. like the following code. Besides, it should add some related doc.

if cluster_resolver.task_type == 'evaluator':
        server = tf.distribute.Server(
            cluster_resolver.cluster_spec(),
            job_name=cluster_resolver.task_type,
            task_index=cluster_resolver.task_id,
            protocol=cluster_resolver.rpc_layer or "grpc",
            start=True)
        # dont need to call server.join()
        checkpoint = tf.train.Checkpoint(model=model)
        ...

In the PS strategy code of tf2.4, the evaluator type should be dynamically ignored to avoid waiting for a long time in coordinator

Standalone code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab/Jupyter/any notebook.
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.

Hi @zuston, just to clarify a few things--does your code run if you remove the evaluator from the cluster? And are there any logs you can share? If I understand correctly, you're suggesting that the even if the evaluator fails to start, the training process should go on?

Hi @zuston, just to clarify a few things--does your code run if you remove the evaluator from the cluster? And are there any logs you can share? If I understand correctly, you're suggesting that the even if the evaluator fails to start, the training process should go on?

Thanks reply @nikitamaia .

does your code run if you remove the evaluator from the cluster?

Yes. when i remove the evaluator from cluster spec. it can run.
Another thing to note is that in my code, the evaluator did not start the rpc server.
So I make extra expriments on PSS. I found that when evaluator in cluster sepc and starting the rpc server  in my code about evaluator, the training job can run normally.
So i think it's unreasonable. Because refer to the tf documentation (link), the evaluator is not a member of the entire training task, but is only responsible for checking checkpoints and evaluating. Therefore coordinator should ignore cluster spec about evaluator. Currently, i think coordinator will wait creating rpc channel with evaluator, so it will hang.

And are there any logs you can share?

OK. i will attach it later.

If I understand correctly, you're suggesting that the even if the evaluator fails to start, the training process should go on?

Yes, but not exactly. I think that evaluator don't need to start rpc server.

Thanks reply @nikitamaia .

does your code run if you remove the evaluator from the cluster?

Yes. when i remove the evaluator from cluster spec. it can run.
Another thing to note is that in my code, the evaluator did not start the rpc server.
So I make extra expriments on PSS. I found that when evaluator in cluster sepc and starting the rpc server  in my code about evaluator, the training job can run normally.
So i think it's unreasonable. Because refer to the tf documentation (link), the evaluator is not a member of the entire training task, but is only responsible for checking checkpoints and evaluating. Therefore coordinator should ignore cluster spec about evaluator. Currently, i think coordinator will wait creating rpc channel with evaluator, so it will hang.

And are there any logs you can share?

OK. i will attach it later.

If I understand correctly, you're suggesting that the even if the evaluator fails to start, the training process should go on?

Yes, but not exactly. I think that evaluator don't need to start rpc server.

Attach related logs.
Coordinator (chief) logs
I0105 12:12:10.884592<PHONE_NUMBER>69184 train.py:53] [2021-01-05 12:12:10] Create variable partitioner...
I0105 12:12:10.885219<PHONE_NUMBER>69184 train.py:55] [2021-01-05 12:12:10] Create strategy...
2021-01-05 12:12:10.886007: I tensorflow/compiler/jit/xla_cpu_device.cc:41] Not creating XLA devices, tf_xla_enable_xla_devices not set
2021-01-05 12:12:10.886360: W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcuda.so.1'; dlerror: libcuda.so.1: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/java/default/jre/lib/amd64/server
2021-01-05 12:12:10.886390: W tensorflow/stream_executor/cuda/cuda_driver.cc:326] failed call to cuInit: UNKNOWN ERROR (303)
2021-01-05 12:12:10.886414: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:156] kernel driver does not appear to be running on this host (localhost): /proc/driver/nvidia/version does not exist
2021-01-05 12:12:10.887107: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX512F
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2021-01-05 12:12:10.897641: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
INFO:tensorflow:ParameterServerStrategy (CentralStorageStrategy if you are using a single machine) with compute_devices = ['/job:localhost/replica:0/task:0/device:CPU:0'], variable_device = '/job:localhost/replica:0/task:0/device:CPU:0'
I0105 12:12:10.909158<PHONE_NUMBER>69184 parameter_server_strategy.py:323] ParameterServerStrategy (CentralStorageStrategy if you are using a single machine) with compute_devices = ['/job:localhost/replica:0/task:0/device:CPU:0'], variable_device = '/job:localhost/replica:0/task:0/device:CPU:0'
INFO:tensorflow:`tf.distribute.experimental.ParameterServerStrategy` is initialized with cluster_spec: ClusterSpec({'chief': ['localhost:11524'], 'evaluator': ['localhost:36867'], 'ps': ['localhost:35270'], 'worker': ['localhost:24572', 'localhost:10920']})
I0105 12:12:10.909924<PHONE_NUMBER>69184 parameter_server_strategy_v2.py:430] `tf.distribute.experimental.ParameterServerStrategy` is initialized with cluster_spec: ClusterSpec({'chief': ['localhost:11524'], 'evaluator': ['localhost:36867'], 'ps': ['localhost:35270'], 'worker': ['localhost:24572', 'localhost:10920']})
INFO:tensorflow:ParameterServerStrategyV2 is now connecting to cluster with cluster_spec: ClusterSpec({'chief': ['localhost:11524'], 'evaluator': ['localhost:36867'], 'ps': ['localhost:35270'], 'worker': ['localhost:24572', 'localhost:10920']})
I0105 12:12:10.911811<PHONE_NUMBER>69184 parameter_server_strategy_v2.py:461] ParameterServerStrategyV2 is now connecting to cluster with cluster_spec: ClusterSpec({'chief': ['localhost:11524'], 'evaluator': ['localhost:36867'], 'ps': ['localhost:35270'], 'worker': ['localhost:24572', 'localhost:10920']})
2021-01-05 12:12:10.912644: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
2021-01-05 12:12:10.938734: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job chief -> {0 -> localhost:11524}
2021-01-05 12:12:10.938802: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job evaluator -> {0 -> localhost:36867}
2021-01-05 12:12:10.938813: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job ps -> {0 -> localhost:35270}
2021-01-05 12:12:10.938820: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job worker -> {0 -> localhost:24572, 1 -> localhost:10920}

worker and ps:
I0105 12:11:59.622877<PHONE_NUMBER>04192 train.py:46] [2021-01-05 12:11:59] NUM_WORKERS: 2, global_batch_size: 2048
I0105 12:11:59.623015<PHONE_NUMBER>04192 train.py:198] [2021-01-05 12:11:59] Start worker(0)...
2021-01-05 12:11:59.623634: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX512F
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2021-01-05 12:11:59.659345: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
2021-01-05 12:11:59.659649: W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcuda.so.1'; dlerror: libcuda.so.1: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/java/default/jre/lib/amd64/server
2021-01-05 12:11:59.659702: W tensorflow/stream_executor/cuda/cuda_driver.cc:326] failed call to cuInit: UNKNOWN ERROR (303)
2021-01-05 12:11:59.659733: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:156] kernel driver does not appear to be running on this host (localhost): /proc/driver/nvidia/version does not exist
2021-01-05 12:11:59.714894: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job chief -> {0 -> localhost:11524}
2021-01-05 12:11:59.714962: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job evaluator -> {0 -> localhost:36867}
2021-01-05 12:11:59.714973: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job ps -> {0 -> localhost:35270}
2021-01-05 12:11:59.714980: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job worker -> {0 -> localhost:24572, 1 -> localhost:10920}
2021-01-05 12:11:59.795589: I tensorflow/core/distributed_runtime/rpc/grpc_server_lib.cc:411] Started server with target: grpc://localhost:24572

evaluator log (not start rpc server):
2021-01-05 12:11:45.403783: E tensorflow/core/platform/hadoop/hadoop_file_system.cc:115] HadoopFileSystem load error: /usr/lib/hadoop-hdfs/lib/native/libhdfs.so: cannot open shared object file: No such file or directory
2021-01-05 12:11:47.924755: I tensorflow/compiler/jit/xla_cpu_device.cc:41] Not creating XLA devices, tf_xla_enable_xla_devices not set
2021-01-05 12:11:47.924980: W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcuda.so.1'; dlerror: libcuda.so.1: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/java/default/jre/lib/amd64/server
2021-01-05 12:11:47.924998: W tensorflow/stream_executor/cuda/cuda_driver.cc:326] failed call to cuInit: UNKNOWN ERROR (303)
2021-01-05 12:11:47.925016: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:156] kernel driver does not appear to be running on this host (localhost): /proc/driver/nvidia/version does not exist
2021-01-05 12:11:47.925418: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX512F
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2021-01-05 12:11:47.928078: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
INFO:tensorflow:Waiting for new checkpoint at hdfs://namenode03-xxxx.hadoop/data/xxx/ranking/xxxxxx/2020-12-25-00/checkpoint
I0105 12:11:58.545091<PHONE_NUMBER>08544 checkpoint_utils.py:139] Waiting for new checkpoint at hdfs://namenode03-xxxx.hadoop/data/xxx/ranking/xxxxxx/2020-12-25-00/checkpoint

Attach related logs.
Coordinator (chief) logs
I0105 12:12:10.884592<PHONE_NUMBER>69184 train.py:53] [2021-01-05 12:12:10] Create variable partitioner...
I0105 12:12:10.885219<PHONE_NUMBER>69184 train.py:55] [2021-01-05 12:12:10] Create strategy...
2021-01-05 12:12:10.886007: I tensorflow/compiler/jit/xla_cpu_device.cc:41] Not creating XLA devices, tf_xla_enable_xla_devices not set
2021-01-05 12:12:10.886360: W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcuda.so.1'; dlerror: libcuda.so.1: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/java/default/jre/lib/amd64/server
2021-01-05 12:12:10.886390: W tensorflow/stream_executor/cuda/cuda_driver.cc:326] failed call to cuInit: UNKNOWN ERROR (303)
2021-01-05 12:12:10.886414: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:156] kernel driver does not appear to be running on this host (localhost): /proc/driver/nvidia/version does not exist
2021-01-05 12:12:10.887107: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX512F
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2021-01-05 12:12:10.897641: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
INFO:tensorflow:ParameterServerStrategy (CentralStorageStrategy if you are using a single machine) with compute_devices = ['/job:localhost/replica:0/task:0/device:CPU:0'], variable_device = '/job:localhost/replica:0/task:0/device:CPU:0'
I0105 12:12:10.909158<PHONE_NUMBER>69184 parameter_server_strategy.py:323] ParameterServerStrategy (CentralStorageStrategy if you are using a single machine) with compute_devices = ['/job:localhost/replica:0/task:0/device:CPU:0'], variable_device = '/job:localhost/replica:0/task:0/device:CPU:0'
INFO:tensorflow:`tf.distribute.experimental.ParameterServerStrategy` is initialized with cluster_spec: ClusterSpec({'chief': ['localhost:11524'], 'evaluator': ['localhost:36867'], 'ps': ['localhost:35270'], 'worker': ['localhost:24572', 'localhost:10920']})
I0105 12:12:10.909924<PHONE_NUMBER>69184 parameter_server_strategy_v2.py:430] `tf.distribute.experimental.ParameterServerStrategy` is initialized with cluster_spec: ClusterSpec({'chief': ['localhost:11524'], 'evaluator': ['localhost:36867'], 'ps': ['localhost:35270'], 'worker': ['localhost:24572', 'localhost:10920']})
INFO:tensorflow:ParameterServerStrategyV2 is now connecting to cluster with cluster_spec: ClusterSpec({'chief': ['localhost:11524'], 'evaluator': ['localhost:36867'], 'ps': ['localhost:35270'], 'worker': ['localhost:24572', 'localhost:10920']})
I0105 12:12:10.911811<PHONE_NUMBER>69184 parameter_server_strategy_v2.py:461] ParameterServerStrategyV2 is now connecting to cluster with cluster_spec: ClusterSpec({'chief': ['localhost:11524'], 'evaluator': ['localhost:36867'], 'ps': ['localhost:35270'], 'worker': ['localhost:24572', 'localhost:10920']})
2021-01-05 12:12:10.912644: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
2021-01-05 12:12:10.938734: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job chief -> {0 -> localhost:11524}
2021-01-05 12:12:10.938802: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job evaluator -> {0 -> localhost:36867}
2021-01-05 12:12:10.938813: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job ps -> {0 -> localhost:35270}
2021-01-05 12:12:10.938820: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job worker -> {0 -> localhost:24572, 1 -> localhost:10920}

worker and ps:
I0105 12:11:59.622877<PHONE_NUMBER>04192 train.py:46] [2021-01-05 12:11:59] NUM_WORKERS: 2, global_batch_size: 2048
I0105 12:11:59.623015<PHONE_NUMBER>04192 train.py:198] [2021-01-05 12:11:59] Start worker(0)...
2021-01-05 12:11:59.623634: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX512F
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2021-01-05 12:11:59.659345: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
2021-01-05 12:11:59.659649: W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcuda.so.1'; dlerror: libcuda.so.1: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/java/default/jre/lib/amd64/server
2021-01-05 12:11:59.659702: W tensorflow/stream_executor/cuda/cuda_driver.cc:326] failed call to cuInit: UNKNOWN ERROR (303)
2021-01-05 12:11:59.659733: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:156] kernel driver does not appear to be running on this host (localhost): /proc/driver/nvidia/version does not exist
2021-01-05 12:11:59.714894: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job chief -> {0 -> localhost:11524}
2021-01-05 12:11:59.714962: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job evaluator -> {0 -> localhost:36867}
2021-01-05 12:11:59.714973: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job ps -> {0 -> localhost:35270}
2021-01-05 12:11:59.714980: I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:301] Initialize GrpcChannelCache for job worker -> {0 -> localhost:24572, 1 -> localhost:10920}
2021-01-05 12:11:59.795589: I tensorflow/core/distributed_runtime/rpc/grpc_server_lib.cc:411] Started server with target: grpc://localhost:24572

evaluator log (not start rpc server):
2021-01-05 12:11:45.403783: E tensorflow/core/platform/hadoop/hadoop_file_system.cc:115] HadoopFileSystem load error: /usr/lib/hadoop-hdfs/lib/native/libhdfs.so: cannot open shared object file: No such file or directory
2021-01-05 12:11:47.924755: I tensorflow/compiler/jit/xla_cpu_device.cc:41] Not creating XLA devices, tf_xla_enable_xla_devices not set
2021-01-05 12:11:47.924980: W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'libcuda.so.1'; dlerror: libcuda.so.1: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib/hadoop/lib/native:/usr/java/default/jre/lib/amd64/server
2021-01-05 12:11:47.924998: W tensorflow/stream_executor/cuda/cuda_driver.cc:326] failed call to cuInit: UNKNOWN ERROR (303)
2021-01-05 12:11:47.925016: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:156] kernel driver does not appear to be running on this host (localhost): /proc/driver/nvidia/version does not exist
2021-01-05 12:11:47.925418: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX512F
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2021-01-05 12:11:47.928078: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
INFO:tensorflow:Waiting for new checkpoint at hdfs://namenode03-xxxx.hadoop/data/xxx/ranking/xxxxxx/2020-12-25-00/checkpoint
I0105 12:11:58.545091<PHONE_NUMBER>08544 checkpoint_utils.py:139] Waiting for new checkpoint at hdfs://namenode03-xxxx.hadoop/data/xxx/ranking/xxxxxx/2020-12-25-00/checkpoint

Any update on it? @nikitamaia

Any update on it? @nikitamaia

Hi, the strategy is probably not at the best position to remove a job from cluster resolvers. As described in the tutorial, training and evaluation clusters are two separate clusters and they should not connect to each other. See https://www.tensorflow.org/tutorials/distribute/parameter_server_training#cluster_setup.
Alternatively, we would recommend you try out inline evaluation and give us feedbacks.

Thanks your reply. @yuefengz
As stated in the above TF doc, the evaluator is indeed not part of the training cluster. But it does not have this problem in TF1.x PS strategy, and related kubeflow/tf-operator and linkedin/tony are also used in this way.
Now it seems that we need to adapt to TF2.x single-client PS strategy in related project.

With V1 PSStrategy, we indeed had some hacks to split the training and evaluation cluster. It makes sense for V2 ParameterServerStrategy to strip the evaluator. But one concern I have is the likelihood of unifying the interfaces of ParameterServerStrategy and TPUStrategy in the future. In that case, we will probably require users to call tf.config.experimental_connect_to_cluster before creating the strategy instance and then users will have to strip the evaluators from TF_CONFIG themselves. The transition would be not smooth if we have this magic right now. Therefore, we started with the least magical way and once we the API becomes more stable, we can consider adding these magics.

Got it. Thank you for your patience~

With V1 PSStrategy, we indeed had some hacks to split the training and evaluation cluster. It makes sense for V2 ParameterServerStrategy to strip the evaluator. But one concern I have is the likelihood of unifying the interfaces of ParameterServerStrategy and TPUStrategy in the future. In that case, we will probably require users to call tf.config.experimental_connect_to_cluster before creating the strategy instance and then users will have to strip the evaluators from TF_CONFIG themselves. The transition would be not smooth if we have this magic right now. Therefore, we started with the least magical way and once we the API becomes more stable, we can consider adding these magics.

I am having similar issues while using nodes other than the master. It still hangs on tf.distribute.ParameterServerStrategy even with running tf.config.experimental_connect_to_cluster with make_master_device_default=False prior to creating the strategy. I am not using a cloud instance.


fix(text): fix horizontal alignment error

Please check if the PR fulfills these requirements

[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Codecov Report

Merging #772 (88d52e9) into main (9314d3a) will decrease coverage by 0.03%.
The diff coverage is 29.72%.

@@            Coverage Diff             @@
##             main     #772      +/-   ##
==========================================
- Coverage   43.71%   43.67%   -0.04%
==========================================
  Files         419      419
  Lines       22822    22855      +33
  Branches     3128     3131       +3
==========================================
+ Hits         9976     9982       +6
- Misses      12846    12873      +27

Impacted Files
Coverage Δ

packages/core/src/2d/sprite/Sprite.ts
20.65% <ø> (+0.11%)
:arrow_up:

packages/core/src/2d/text/TextRenderer.ts
43.65% <0.00%> (-1.52%)
:arrow_down:

packages/core/src/index.ts
96.39% <ø> (+0.03%)
:arrow_up:

packages/core/src/mesh/BlendShapeManager.ts
66.13% <0.00%> (ø)

packages/core/src/mesh/PrimitiveMesh.ts
1.19% <0.00%> (ø)

...ges/physics-lite/src/shape/LiteBoxColliderShape.ts
0.00% <ø> (ø)

packages/loader/src/gltf/parser/AnimationParser.ts
57.57% <50.00%> (-6.46%)
:arrow_down:

packages/core/src/input/InputManager.ts
36.17% <0.00%> (-1.04%)
:arrow_down:

... and 3 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6400307...88d52e9. Read the comment docs.


closes #1839 onboarding dummy function created

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the devel branch until you have checked off each task.

[x] Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
[x] Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
[x] Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
[x] If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
[x] Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
[x] Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
[x] Address any updates needed for vignettes and/or templates
[x] Update NEWS.md if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
[x] Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
[x] Address or fix all lintr warnings and errors - lintr::lint_package()
[x] Run R CMD check locally and address all errors and warnings - devtools::check()
[x] Link the issue in the Development Section on the right hand side.
[x] Address all merge conflicts and resolve appropriately
[x] Pat yourself on the back for a job well done! Much love to your accomplishment!

Just use this and push up and we should be good to go!

Wordlist updated!
Should I close the pull request now, @bms63?

Yes please close- after the Check Templates action is completed.  This only happens after someone approves a PR.

Thanks for the guidance and help, @bms63.
I'll take a look at #1875.


New package: Bilibili.CheeseStudio version 1.1.0

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.4 schema?

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/110184&drop=dogfoodAlpha

@wingetbot waivers Add Validation-Domain

This package didn't complete installing on a Windows 11 VM:

Is it missing a dependency?

This installer can download vcredist from their server and install it automatically during installation. Maybe a network issue?

This installer can download vcredist from their server and install it automatically during installation. Maybe a temporary network issue?

Unfortunately, the issue persists. Is there an installer switch to skip? Maybe it can be specified as a dependency.

It always downloads and installs the vcredist and there is no switch to skip it.
I think the problem is that the vcredist it downloaded is not the latest, which will exit immediately when a newer version is found.


CI - prevent duplicate message names in the same java namespace

Description of the issue
Problem
The current proto definitions in cirq_google/api/v2 contain duplicate message names CZPowGate and InternalGate which get exported to the same java_package namespace.  This causes broken builds for internal projects that use these protos in java form.
Proposed Solution

[ ] fix name overlap by either renaming new messages or using separate java namespace
[ ] add CI check to block PRs that introduce message name overlap

Cirq version
1.5.0.dev at 756abe31d9b1aba6a7073253852cb0151d51cbef

More context - the name overlap could be worked around in the internal application without changing proto definitions here.  No need for fix as reported.


Siad has exited unexpectedly. Please submit a bug report including the error log here.

BUG REPORT
Siad has exited unexpectedly. Please submit a bug report including the error log here.
Error Log:
Sia Daemon v1.3.2
Git Revision 72938f5
Loading...
listen tcp <IP_ADDRESS>:9980: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Stack Trace or error message
Expected Behavior
How to reproduce it (as minimally and precisely as possible)
Environment

Sia version: Sia-UI-v1.3.2-win32-x64
OS:

kill all siad processes

how to kill? That means delete Sia-UI-v1.3.2-win32-x64 and re-install? Thank you for your kind help.

Find siad in task manager and kill.


lts/* installs old LTS version intermittently

Description:
Using the following configuration installs Node.js 20.10.0, an old version. Node.js 20.11.0 has been out since 10 Jan 2024.
      - uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
          check-latest: true

The output looks like this:
Run actions/setup-node@v4
  with:
    node-version: lts/*
    always-auth: false
    check-latest: true
    token: ***
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/20.10.0/x64
Environment details
  node: v20.10.0
  npm: 10.2.3
  yarn: 1.22.21

Action version:
actions/setup-node@v4
Platform:

[x] Ubuntu
[ ] macOS
[ ] Windows

Runner type:

[x] Hosted
[ ] Self-hosted

Tools version:

Node.js lts/*
  node: v20.10.0
  npm: 10.2.3
  yarn: 1.22.21

Repro steps:
Use the configuration above and observe the output above
Expected behavior:
Node.js latest LTS (20.11.0) is installed
Actual behavior:
Node.js older LTS (20.10.0) is installed
cc @MaksimZhukov @dmitry-shibanov @dusan-trickovic

Looks like the manifest might be here (maybe this should be linked in the output of actions/setup-node for easier debugging, if this will continue to be potentially problematic in future?):

https://github.com/actions/node-versions/blob/main/versions-manifest.json

I opened a PR there as well, in case that's a better place to discuss:

https://github.com/actions/node-versions/pull/162

Hello @karlhorky
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.

Hello @karlhorky
The latest version 20.11.0 is merged in node-versions repository. Could you please confirm if the latest version is reflecting at your end.
If you have any concerns please feel free to ping us.

@HarithaVattikuti I just tried re-running my job and it's still on Node.js 20.10.0
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/20.10.0/x64

Is there any way I can manually clear the manifest cache on GitHub Actions?
I know that you can clear other named caches, but these are unrelated to the manifest cache, from what I can tell.

Hello karlhorky, We have tried to reproduce the issue and unable to do so. Below is the screenshot of the same.

Please share a sample repo with minimum code to reproduce the issue.
Feel free to reach out to us in case of any issues

@HarithaVattikuti now it's working, thanks!
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/20.11.0/x64

Maybe I tried it before the change was fully rolled out.

Interesting, this is still intermittently failing on some of our repositories:
Attempt to resolve LTS alias from manifest...
Found in cache @ /Users/runner/hostedtoolcache/node/20.10.0/x64

https://github.com/upleveled/hotline-bling-codealong/actions/runs/7667389682/job/20897108024?pr=164

@HarithaVattikuti maybe there's a problem with the caches?
Reopening for visibility.

Hello @karlhorky,
According to your repository set up-node is run on different OS. The hostedtoolcache will reflect the latest node version from the OS image. For Ex: In MacOS-12 Image Cached Tool of node is 20.11.0 but in MacOS-13 Image cached Tool of node is still 20.10.0.
https://github.com/actions/runner-images/blob/macOS-12/20240119.1/images/macos/macos-13-Readme.md#cached-tools
https://github.com/actions/runner-images/blob/macOS-12/20240119.1/images/macos/macos-12-Readme.md#cached-tools
Please use the related OS image for latest node version 20.11.0.
Closing this issue as it is not part of our scope.
Feel Free to reach out to us in case of any issues.

Oh wow, that's a surprising detail 🤔
To me, it seems like Node.js lts/* should be the latest Node.js LTS, not an older cached version.
If it would be possible to fix that and return the latest LTS, I'm sure that would be widely appreciated and reduce confusion.

Update: this continues to be a problem with Node.js v20.12.0 - the lts/* specifier does not install 20.12.0, which has been out for over 5 days now:
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
          cache: 'pnpm'

Logs for the workflow run:
Run actions/setup-node@v4

Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/20.11.1/x64
Environment details
/home/runner/setup-pnpm/node_modules/.bin/pnpm store path --silent
/home/runner/setup-pnpm/node_modules/.bin/store/v3
Received 0 of 177801572 (0.0%), 0.0 MBs/sec
Received 125829120 of 177801572 (70.8%), 60.0 MBs/sec
Cache Size: ~170 MB (177801572 B)
/usr/bin/tar -xf /home/runner/work/_temp/36665e6f-3c08-4aa9-a645-44132e6[14](https://github.com/upleveled/preflight-test-project-next-js-passing/actions/runs/8507621988/job/23299779905?pr=152#step:7:14)367/cache.tzst -P -C /home/runner/work/preflight-test-project-next-js-passing/preflight-test-project-next-js-passing --use-compress-program unzstd
Received 17780[15](https://github.com/upleveled/preflight-test-project-next-js-passing/actions/runs/8507621988/job/23299779905?pr=152#step:7:16)72 of 177801572 (100.0%), 56.5 MBs/sec
Cache restored successfully
Cache restored from key: node-cache-Linux-pnpm-4ef79db9b37b4913d3034ac221942fa51b304d30abec481a5894d6356c04e3e6

@HarithaVattikuti can you reopen this issue please?
Or if not, I'll create a new issue.

@aparnajyothi-y if you are taking this over, could you reopen this issue?

Hello @karlhorky, I have tried to run the same job to use lts* in my local and it is downloading the latest version 20.12.0.
If a previous LTS version was cached in the runner, actions/setup-node might reuse the cached version instead of fetching the latest one. As a workaround, we need to explicitly setting the cache input to 'none' in the actions/setup-node step of your job. This will prevent actions/setup-node from using a cached version of Node.js.
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 'lts/*'
cache: 'none'
If we want to keep the caching but ensure that always using the latest LTS version then add a step to your workflow that updates Node.js to the latest LTS version after setting it up
    - name: Setup Node.js
              uses: actions/setup-node@v4
              with:
                  node-version: 'lts/*'

   - name: Update to latest LTS version
      run: |
        npm install -g n
        sudo n lts
        echo ""NODE_PATH=$(npm root --quiet -g)"" >> $GITHUB_ENV.

@aparnajyothi-y what I think should be supported (and would be the behavior that users would expect and want):

lts/* retrieves the latest Node.js version
The cache is used when it is available
The cache is evicted *without user intervention* when any new LTS version is released (from my understanding, this is probably where setup-node could be fixed)
No additional configuration such as cache: 'none' is required
No additional obscure steps (such as installing a Node.js version manager) are required

Hello @karlhorky, We have furthermore investigated and found that the action itself doesn't control the cache, it's managed by the runner environment. Automatic cache eviction may need changes on the runner's side as setup-node uses the caching facilities provided by the runner environment, you can refer here. Automatic cache eviction is a potential feature where old or unused cached dependencies would be automatically removed. This ensures that the cache does not keep growing indefinitely and consume all available storage.
Using cache when available is actually a part of the Setup-action's functionality. The action will check if the required Node.js version is in the cache and use it if it's available. By caching these dependencies, subsequent runs of the workflow can be faster as they can reuse the cached dependencies instead of downloading them again.
Please let us know in case of any further clarification.

Ok, so if I'm understanding what you're saying, this bug should be reported somewhere else?
Where exactly can this be reported so that the behavior is automatic upgrades of the cache on new LTS versions?

I'm not sure I'm understanding what you're saying, but maybe you're saying this bug should be also reported somewhere else?
Where exactly can this be reported also for the runners so that the behavior is automatic cache evictions (or cache upgrades) on new LTS versions?
I and others think that the current behavior is broken, so it should be fixed.
I assume it may not be the runner's responsibility to know about new LTS versions of Node.js (that seems like responsibility of actions/setup-node) - it may actually be a split responsibility: both actions/setup-node and also in the runner environments:

To me, it seems that logically, the place that would be related to "performing some action when a new LTS version is released" would be actions/setup-node (this current repo)
But in this case, the action needs to evict the cache, where you mentioned the management is the responsibility of the runner

So, if this mental model is correct, there may need to be a "cache eviction API" exposed by the runner, in order for actions/setup-node to be able to evict the cache on new LTS versions.

Hello @karlhorky, As we have mentioned in the above comment, this feature might be shared between the actions/setup-node and the GitHub Actions runner. The actions/setup-node should ideally handle actions related to the release of new LTS versions, while cache management is typically handled by the runner.
If we got ""cache eviction API"" support in the runner, that would allow actions like actions/setup-node to evict the cache when new LTS versions are released, ensuring that the cache is always up-to-date.
Please let us know in case of any clarification is needed from setup-node. Thank you.

Ok great, are you a part of the GitHub Actions team?
Can you reach out to someone internal on the runner side to convey the need for a Cache Eviction API to allow for the actions/setup-node LTS version identifier lts/* to use the latest LTS release without user interaction?
I see that the following people are maintainers / contributors on the public GitHub repos, but I have no visibility / connections beyond that:

https://github.com/actions/runner

@TingluoHuang @luketomlinson @nikola-jokic

https://github.com/actions/runner-images

@Alexey-Ayupov @mikhailkoliada @erik-bershel @MaksimZhukov

Hello @karlhorky, We are discussing with the runner-images about the possibility of the cache eviction feature from the runner-images . Please raise an issue in the runner-images repository to request support for this feature as discussed in the above comment and we can add the facility for cache eviction for LTS versions from setup-actions once we receive that feature from runner-images.
Please feel free to reach us in case of any further clarifications.

Done, request open here:

https://github.com/actions/runner-images/issues/10311

Ok, I'm not sure of the implementation details or inner workings.
But maybe we can agree that node-version: 'lts/*' retrieving an old version is not only a bad UX, but also sometimes a security risk.

Hello @karlhorky, As @mikhailkoliada mentioned, cache eviction should not be handled on the runner side; instead, cache management should be performed through the task itself. The latest Node.js version, 20.15.1, is available with runner images on both Ubuntu 20 and 22 runners. We are looking for version 20.11.0, which is outdated and Installing the required version at runtime through the workflow is the best workaround.
We are proceeding to close this issue as it is confirmed that cache eviction is not possible through runner-images. Please feel free to reach out if you have any concerns or need further information.

We are proceeding to close this issue as it is confirmed that cache eviction is not possible through runner-images

Where is this confirmed? I opened this issue and it's now been assigned:

https://github.com/actions/runner-images/issues/10311

This issue should stay open, because there is still an active bug in actions/setup-node - the following config will intermittently lead to old, stale LTS versions being used:
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'

This is an unexpected and broken behavior for users, and can lead to security problems. Please reconsider leaving this issue open.

Maybe it should just be publicly recommended to avoid using actions/setup-node because of this problem.
Eg. if it's impossible for the teams at GitHub to write code to retrieve the latest LTS version when a new one is released, maybe users should be suggested to switch to third party alternatives from the community like https://github.com/dcodeIO/setup-node-nvm (GitHub Marketplace)
uses: dcodeIO/setup-node-nvm@master
with:
  node-version: lts/*

Which would work reliably, unlike actions/setup-node.

@aparnajyothi-y Since it appears that this issue is closed now as a "won't fix", I opened a PR to add a warning to the readme about NVM syntax here, and steer users away from actions/setup-node if they use this syntax:

https://github.com/actions/setup-node/pull/1114

I opened a PR to add a warning to the readme about NVM syntax here, and steer users away from actions/setup-node if they use this syntax:

https://github.com/actions/setup-node/pull/1114

@aparnajyothi-y I'm not sure why this issue is closed now.
Can you reopen and leave open until it's resolved?
If you close the issue, users will be unable to find this problem, which is still an open, unresolved problem in actions/setup-node.

Workaround
Full replacement for broken actions/setup-node version resolution, with nvm:
      # Use nvm because actions/setup-node does not install latest versions
      # https://github.com/actions/setup-node/issues/940
      - name: Install latest LTS with nvm
        run: |
          nvm install 'lts/*'
          rm /usr/local/bin/node
          ln -s $(which node) /usr/local/bin/node
        shell: bash -l {0}
      - name: Get pnpm store directory
        shell: bash
        run: |
          echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
      - uses: actions/cache@v4
        name: Setup pnpm cache
        with:
          path: ${{ env.STORE_PATH }}
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-pnpm-store-

Also posted on github-tricks: https://github.com/karlhorky/github-tricks/blob/main/readme.md#github-actions-correct-broken-actionssetup-node-version-resolution

Hello @karlhorky , Thank for your proposals and apologies for the delay in response.
When setup-node action was implemented initially, we designed it to optimize workflow duration to speed up customers' workflows and reduce VM cost for customers. It is why check-latest is disabled by default and action fallbacks to cached version of Node.js on VM. It allows to speed up workflows by 10-15 seconds. Usually, VM cache is up-to-date and it can be 5-6 days old in worst case which is acceptable for the most of customers.
If some customers need to always use the freshest version of Node.js, ""check-latest"" flag is intended for it. If ""check-latest: true"" is passed, action will ignore VM cache and always download latest version.
So, using version: lts/* with check-latest: true will give you exact behaviour which you expect. We have pretty good documentation in repo to explain this behavior: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#check-latest-version
We don't have plans to set check-latest: true by default because it will cause increasing action execution duration for all customers because Node.js will always download on-flight.

When setup-node action was implemented initially, we designed it to optimize workflow duration to speed up customers' workflows and reduce VM cost for customers

This is good. Speed and reduction of cost / resource usage is great.

Usually, VM cache is up-to-date and it can be 5-6 days old in worst case which is acceptable for the most of customers.

For the "which is acceptable for most of customers" assertion, where do you get the data from? Have you spoken with a high number of customers who use a version specifier like lts/* and asked whether they think it's ok that it downloads old versions? Or is it just an assumption that you and the team have? Have you considered security releases of Node.js too, where it is often important to upgrade faster?
My assumption would be the opposite - lts/* and other version specifiers downloading old versions because of caching for multiple days is confusing, buggy, broken behavior that will lead users to waste time debugging.
I could imagine a short delay would be acceptable (between 1-3 hours after release), but even that is able to be mitigated with a proper cache design.

If some customers need to always use the freshest version of Node.js, ""check-latest"" flag is intended for it. If ""check-latest: true"" is passed, action will ignore VM cache and always download latest version.
So, using version: lts/* with check-latest: true will give you exact behaviour which you expect.

First of all, if you read the original post again, I used check-latest: true and this was failing to retrieve the latest version. So this feature is also broken (or at least it was, when I reported the issue).
Also, this is *not* the behavior I'm looking for, nor should it be the solution proposed to customers, let me demonstrate:
1. actions/setup-node@v4 with node-version: 'lts/*'

👍 Uses the cache every time - performant
👎 The cache can be multiple days stale, leading to old versions

2. actions/setup-node@v4 with node-version: 'lts/*' and check-latest: true

👎 Uses no cache every time - slow
👍 The cache is always fresh

Neither of those options are good.
I'm proposing a 3rd option, which is in my opinion how the caching should have been designed from the start.
3. actions/setup-node@v4 with node-version: 'lts/*' (new default behavior)

👍 Uses the cache every time - performant
👍 The cache is invalidated remotely, when a new Node.js version is released, leading to fresh versions

There should be no check-latest option.

Actually, maybe there's even more to be improved here, if actions/setup-node changed its design from the manifest + hosted tool cache to the built-in nvm:

It is why check-latest is disabled by default and action fallbacks to cached version of Node.js on VM. It allows to speed up workflows by 10-15 seconds

It only takes 3 additional seconds to download a fresh copy of Node.js via nvm:
actions/setup-node@v4 with manifest + hosted tool cache
8 seconds total

nvm with no Node.js cache
11 seconds total

Don't be confused by actions/cache - in both cases this is used for pnpm store cache - unrelated to the Node.js cache.
So an alternative would be that actions/setup-node could probably be faster by using nvm in some way.


Docker Security Scanning safeguards the container content lifecycle(binary level scanning )

As your public cloud customers，I want to know the binary-level analysis of every layer,and match the underlying signatures of each binary to known components and cross reference that with a database of known vulnerabilities.  what is the "a database of known vulnerabilities"? I know the CVE have no SHA of the package.

Can you send your question to<EMAIL_ADDRESS>Docker Security Scanning is managed by a different team, and unfortunately, we can't answer that in this repository


[BUG] Textures aren't displaying in the TextureBrowser

After converting the AssetManager to C# I had to make a few changes. Which have strangely resulted in textures not loading properly?

Currently investigating what could cause this. It seems that the textures are indeed being found and loaded properly to some degree

UPDATE: After realizing I forgot a line to set the texture rect in the primitive pane it IS indeed loading the textures! But something else is going on with both the primitive and the TextureBrowser class

https://github.com/ashifolfi/Chisel/commit/6303ed0f85365ca7fa8f4d4a33407621648414d5 Fixed the texturerect and primitive issues


Support interpreter on arm

The interpreter currently doesn't build on arm. Codegen fails with the error message LLVM ERROR: Cannot generate unaligned atomic store.
Extracted from #12298

Would love to run this on my Raspberry Pi 5.


Qflow GUI

Hello everyone,
I am newbie to Qflow and open source VLSI flow. I have a question about Qflow and this pdk.
Is there any way to see and use these libraries in qflow_gui "Preparation" part like OSU_035 ?

The best way is to have a symbolic link called "tech" in the same directory as you create a project that is a link to the qflow setup in sky130A;  e.g., for the default install, ln -s /usr/share/pdk/sky130A/libs.tech/qflow tech.  Make this symbolic link before you run qflow gui, and you should be able to see all of the digital standard cell libraries in the qflow GUI.
A word of warning:  The high-density standard cells do not work very well with qflow;  it will generate a lot of DRC errors.  Use the "HS", "MS", and "LS" libraries to minimize the number of DRC issues (I have not had the time to debug some of the more common problems, but the number of DRC errors is manageable for small-ish designs).

Hello,
Thanks a lot for your reply.
However, when I used openpdk libs synthesis gives me an error. Synth.log is shown below.
If I used OSU018,this error didn't happen.
Qflow synthesis logfile created on Sal Ağu 10 19:49:45 +03 2021
Running yosys for verilog parsing and synthesis
yosys  -s fulladder.ys
/----------------------------------------------------------------------------
|                                                                            |
|  yosys -- Yosys Open SYnthesis Suite                                       |
|                                                                            |
|  Copyright (C) 2012 - 2016  Clifford Wolf<EMAIL_ADDRESS>         |
|                                                                            |
|  Permission to use, copy, modify, and/or distribute this software for any  |
|  purpose with or without fee is hereby granted, provided that the above    |
|  copyright notice and this permission notice appear in all copies.         |
|                                                                            |
|  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES  |
|  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF          |
|  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR   |
|  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES    |
|  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN     |
|  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF   |
|  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.            |
|                                                                            |
----------------------------------------------------------------------------/
Yosys 0.7 (git sha1 61f6811, gcc 6.2.0-11ubuntu1 -O2 -fdebug-prefix-map=/build/yosys-OIL3SR/yosys-0.7=. -fstack-protector-strong -fPIC -Os)
-- Executing script file `fulladder.ys' --

Executing Liberty frontend.
Imported 376 cell types from liberty file.

Executing Verilog-2005 frontend.
Parsing Verilog input from /home/burakt/Desktop/ASIC/adder2/source/adder.v' to AST representation. Generating RTLIL representation for module \fulladder'.
Generating RTLIL representation for module `\rippe_adder'.
Successfully finished Verilog frontend.

Executing SYNTH pass.

3.1. Executing HIERARCHY pass (managing design hierarchy).
3.1.1. Analyzing design hierarchy..
Top module:  \fulladder
3.1.2. Analyzing design hierarchy..
Top module:  \fulladder
Removing unused module `\rippe_adder'.
Removed 1 unused modules.
3.2. Executing PROC pass (convert processes to netlists).
3.2.1. Executing PROC_CLEAN pass (remove empty switches from decision trees).
Cleaned up 0 empty switches.
3.2.2. Executing PROC_RMDEAD pass (remove dead branches from decision trees).
 Executing PROC_INIT pass (extract init attributes).
3.2.4. Executing PROC_ARST pass (detect async resets in processes).
3.2.5. Executing PROC_MUX pass (convert decision trees to multiplexers).
3.2.6. Executing PROC_DLATCH pass (convert process syncs to latches).
3.2.7. Executing PROC_DFF pass (convert process syncs to FFs).
3.2.8. Executing PROC_CLEAN pass (remove empty switches from decision trees).
Cleaned up 0 empty switches.
3.3. Executing OPT_EXPR pass (perform const folding).
3.4. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.5. Executing CHECK pass (checking for obvious problems).
checking module fulladder..
found and reported 0 problems.
3.6. Executing OPT pass (performing simple optimizations).
3.6.1. Executing OPT_EXPR pass (perform const folding).
3.6.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.6.3. Executing OPT_MUXTREE pass (detect dead branches in mux trees).
Running muxtree optimizer on module \fulladder..
Creating internal representation of mux trees.
No muxes found in this module.
Removed 0 multiplexer ports.
3.6.4. Executing OPT_REDUCE pass (consolidate $mux and $reduce_ inputs).
Optimizing cells in module \fulladder.
Performed a total of 0 changes.
3.6.5. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.6.6. Executing OPT_RMDFF pass (remove dff with constant values).
3.6.7. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.6.8. Executing OPT_EXPR pass (perform const folding).
3.6.9. Finished OPT passes. (There is nothing left to do.)
3.7. Executing WREDUCE pass (reducing word size of cells).
3.8. Executing ALUMACC pass (create $alu and $macc cells).
Extracting $alu and $macc cells in module fulladder:
created 0 $alu and 0 $macc cells.
3.9. Executing SHARE pass (SAT-based resource sharing).
3.10. Executing OPT pass (performing simple optimizations).
3.10.1. Executing OPT_EXPR pass (perform const folding).
3.10.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.10.3. Executing OPT_MUXTREE pass (detect dead branches in mux trees).
Running muxtree optimizer on module \fulladder..
Creating internal representation of mux trees.
No muxes found in this module.
Removed 0 multiplexer ports.
3.10.4. Executing OPT_REDUCE pass (consolidate $mux and $reduce_ inputs).
Optimizing cells in module \fulladder.
Performed a total of 0 changes.
3.10.5. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.10.6. Executing OPT_RMDFF pass (remove dff with constant values).
3.10.7. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.10.8. Executing OPT_EXPR pass (perform const folding).
3.10.9. Finished OPT passes. (There is nothing left to do.)
3.11. Executing FSM pass (extract and optimize FSM).
3.11.1. Executing FSM_DETECT pass (finding FSMs in design).
3.11.2. Executing FSM_EXTRACT pass (extracting FSM from design).
3.11.3. Executing FSM_OPT pass (simple optimizations of FSMs).
3.11.4. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.11.5. Executing FSM_OPT pass (simple optimizations of FSMs).
3.11.6. Executing FSM_RECODE pass (re-assigning FSM state encoding).
3.11.7. Executing FSM_INFO pass (dumping all available information on FSM cells).
3.11.8. Executing FSM_MAP pass (mapping FSMs to basic logic).
3.12. Executing OPT pass (performing simple optimizations).
3.12.1. Executing OPT_EXPR pass (perform const folding).
3.12.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.12.3. Executing OPT_RMDFF pass (remove dff with constant values).
3.12.4. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.12.5. Finished fast OPT passes.
3.13. Executing MEMORY pass.
3.13.1. Executing MEMORY_DFF pass (merging $dff cells to $memrd and $memwr).
3.13.2. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.13.3. Executing MEMORY_SHARE pass (consolidating $memrd/$memwr cells).
3.13.4. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.13.5. Executing MEMORY_COLLECT pass (generating $mem cells).
3.14. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.15. Executing OPT pass (performing simple optimizations).
3.15.1. Executing OPT_EXPR pass (perform const folding).
3.15.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.15.3. Executing OPT_RMDFF pass (remove dff with constant values).
3.15.4. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.15.5. Finished fast OPT passes.
3.16. Executing MEMORY_MAP pass (converting $mem cells to logic and flip-flops).
3.17. Executing OPT pass (performing simple optimizations).
3.17.1. Executing OPT_EXPR pass (perform const folding).
3.17.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.17.3. Executing OPT_MUXTREE pass (detect dead branches in mux trees).
Running muxtree optimizer on module \fulladder..
Creating internal representation of mux trees.
No muxes found in this module.
Removed 0 multiplexer ports.
3.17.4. Executing OPT_REDUCE pass (consolidate $mux and $reduce_ inputs).
Optimizing cells in module \fulladder.
Performed a total of 0 changes.
3.17.5. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.17.6. Executing OPT_RMDFF pass (remove dff with constant values).
3.17.7. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.17.8. Executing OPT_EXPR pass (perform const folding).
3.17.9. Finished OPT passes. (There is nothing left to do.)
3.18. Executing TECHMAP pass (map to technology primitives).
3.18.1. Executing Verilog-2005 frontend.
Parsing Verilog input from <techmap.v>' to AST representation. Generating RTLIL representation for module _90_simplemap_bool_ops'.
Generating RTLIL representation for module \_90_simplemap_reduce_ops'. Generating RTLIL representation for module _90_simplemap_logic_ops'.
Generating RTLIL representation for module \_90_simplemap_compare_ops'. Generating RTLIL representation for module _90_simplemap_various'.
Generating RTLIL representation for module \_90_simplemap_registers'. Generating RTLIL representation for module _90_shift_ops_shr_shl_sshl_sshr'.
Generating RTLIL representation for module \_90_shift_shiftx'. Generating RTLIL representation for module _90_fa'.
Generating RTLIL representation for module \_90_lcu'. Generating RTLIL representation for module _90_alu'.
Generating RTLIL representation for module \_90_macc'. Generating RTLIL representation for module _90_alumacc'.
Generating RTLIL representation for module \$__div_mod_u'. Generating RTLIL representation for module $__div_mod'.
Generating RTLIL representation for module \_90_div'. Generating RTLIL representation for module _90_mod'.
Generating RTLIL representation for module \_90_pow'. Generating RTLIL representation for module _90_pmux'.
Generating RTLIL representation for module `_90_lut'.
Successfully finished Verilog frontend.
Mapping fulladder.$xor$/home/burakt/Desktop/ASIC/adder2/source/adder.v:6$1 ($xor) with simplemap.
Mapping fulladder.$xor$/home/burakt/Desktop/ASIC/adder2/source/adder.v:7$2 ($xor) with simplemap.
Mapping fulladder.$and$/home/burakt/Desktop/ASIC/adder2/source/adder.v:8$3 ($and) with simplemap.
Mapping fulladder.$and$/home/burakt/Desktop/ASIC/adder2/source/adder.v:9$4 ($and) with simplemap.
Mapping fulladder.$or$/home/burakt/Desktop/ASIC/adder2/source/adder.v:10$5 ($or) with simplemap.
No more expansions possible.
3.19. Executing OPT pass (performing simple optimizations).
3.19.1. Executing OPT_EXPR pass (perform const folding).
3.19.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.19.3. Executing OPT_RMDFF pass (remove dff with constant values).
3.19.4. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
3.19.5. Finished fast OPT passes.
3.20. Executing ABC pass (technology mapping using ABC).
3.20.1. Extracting gate netlist of module \fulladder' to /input.blif'..
Extracted 5 gates and 8 wires to a netlist network with 3 inputs and 2 outputs.
<IP_ADDRESS>. Executing ABC.
Running ABC command: berkeley-abc -s -f /abc.script 2>&1
ABC: ABC command line: "source /abc.script".
ABC:
ABC: + read_blif /input.blif
ABC: + read_library /stdcells.genlib
ABC: Entered genlib library with 15 gates from file "/stdcells.genlib".
ABC: + retime -o
ABC: + map
ABC: Warning: The network was strashed and balanced before mapping.
ABC: + write_blif /output.blif
<IP_ADDRESS>. Re-integrating ABC results.
 Executing OPT pass (performing simple optimizations).
3.21.1. Executing OPT_EXPR pass (perform const folding).
3.21.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
3.21.3. Executing OPT_RMDFF pass (remove dff with constant values).
3.21.4. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
removing unused non-port wire \w1.
removing unused non-port wire \w2.
removing unused non-port wire \w3.
removed 3 unused temporary wires.
3.21.5. Finished fast OPT passes.
3.22. Executing HIERARCHY pass (managing design hierarchy).
3.22.1. Analyzing design hierarchy..
Top module:  \fulladder
3.22.2. Analyzing design hierarchy..
Top module:  \fulladder
Removed 0 unused modules.
3.23. Printing statistics.
=== fulladder ===
Number of wires:                  8
Number of wire bits:              8
Number of public wires:           5
Number of public wire bits:       5
Number of memories:               0
Number of memory bits:            0
Number of processes:              0
Number of cells:                  5
$NAND                         1
$NOT                          1
$OAI3                         1
$XNOR                         1
$XOR                          1
3.24. Executing CHECK pass (checking for obvious problems).
checking module fulladder..
found and reported 0 problems.

Executing DFFLIBMAP pass (mapping DFF cells to sequential cells from liberty file).
cell sky130_fd_sc_hs__dfxtp_1 (noninv, pins=3, area=27.17) is a direct match for cell type $DFF_P.
cell sky130_fd_sc_hs__dfrtn_1 (noninv, pins=4, area=36.76) is a direct match for cell type $DFF_NN0.
cell sky130_fd_sc_hs__dfrtp_1 (noninv, pins=4, area=36.76) is a direct match for cell type $DFF_PN0.
cell sky130_fd_sc_hs__dfstp_1 (noninv, pins=4, area=36.76) is a direct match for cell type $DFF_PN1.
cell sky130_fd_sc_hs__dfbbn_1 (noninv, pins=6, area=44.76) is a direct match for cell type $DFFSR_NNN.
cell sky130_fd_sc_hs__dfbbp_1 (noninv, pins=6, area=43.16) is a direct match for cell type $DFFSR_PNN.
create mapping for $DFF_NP0 from mapping for $DFF_NN0.
create mapping for $DFF_PP0 from mapping for $DFF_PN0.
create mapping for $DFF_PP1 from mapping for $DFF_PN1.
create mapping for $DFFSR_NPN from mapping for $DFFSR_NNN.
create mapping for $DFFSR_PPN from mapping for $DFFSR_PNN.
create mapping for $DFFSR_NNP from mapping for $DFFSR_NNN.
create mapping for $DFFSR_NPP from mapping for $DFFSR_NNP.
create mapping for $DFFSR_PNP from mapping for $DFFSR_PNN.
create mapping for $DFFSR_PPP from mapping for $DFFSR_PNP.
create mapping for $DFF_NN1 from mapping for $DFF_NN0.
create mapping for $DFF_NP1 from mapping for $DFF_NN1.
create mapping for $DFF_N from mapping for $DFF_P.
final dff cell mappings:
sky130_fd_sc_hs__dfxtp_1 DFF_N (.CLK(~C), .D( D), .Q( Q));
sky130_fd_sc_hs__dfxtp_1 DFF_P (.CLK( C), .D( D), .Q( Q));
sky130_fd_sc_hs__dfrtn_1 DFF_NN0 (.CLK_N( C), .D( D), .Q( Q), .RESET_B( R));
sky130_fd_sc_hs__dfrtn_1 DFF_NN1 (.CLK_N( C), .D(~D), .Q(~Q), .RESET_B( R));
sky130_fd_sc_hs__dfrtn_1 DFF_NP0 (.CLK_N( C), .D( D), .Q( Q), .RESET_B(~R));
sky130_fd_sc_hs__dfrtn_1 DFF_NP1 (.CLK_N( C), .D(~D), .Q(~Q), .RESET_B(~R));
sky130_fd_sc_hs__dfrtp_1 DFF_PN0 (.CLK( C), .D( D), .Q( Q), .RESET_B( R));
sky130_fd_sc_hs__dfstp_1 DFF_PN1 (.CLK( C), .D( D), .Q( Q), .SET_B( R));
sky130_fd_sc_hs__dfrtp_1 DFF_PP0 (.CLK( C), .D( D), .Q( Q), .RESET_B(~R));
sky130_fd_sc_hs__dfstp_1 DFF_PP1 (.CLK( C), .D( D), .Q( Q), .SET_B(~R));
sky130_fd_sc_hs__dfbbn_1 DFFSR_NNN (.CLK_N( C), .D( D), .Q( Q), .Q_N(~Q), .RESET_B( R), .SET_B( S));
sky130_fd_sc_hs__dfbbn_1 DFFSR_NNP (.CLK_N( C), .D( D), .Q( Q), .Q_N(~Q), .RESET_B(~R), .SET_B( S));
sky130_fd_sc_hs__dfbbn_1 DFFSR_NPN (.CLK_N( C), .D( D), .Q( Q), .Q_N(~Q), .RESET_B( R), .SET_B(~S));
sky130_fd_sc_hs__dfbbn_1 DFFSR_NPP (.CLK_N( C), .D( D), .Q( Q), .Q_N(~Q), .RESET_B(~R), .SET_B(~S));
sky130_fd_sc_hs__dfbbp_1 DFFSR_PNN (.CLK( C), .D( D), .Q( Q), .Q_N(~Q), .RESET_B( R), .SET_B( S));
sky130_fd_sc_hs__dfbbp_1 DFFSR_PNP (.CLK( C), .D( D), .Q( Q), .Q_N(~Q), .RESET_B(~R), .SET_B( S));
sky130_fd_sc_hs__dfbbp_1 DFFSR_PPN (.CLK( C), .D( D), .Q( Q), .Q_N(~Q), .RESET_B( R), .SET_B(~S));
sky130_fd_sc_hs__dfbbp_1 DFFSR_PPP (.CLK( C), .D( D), .Q( Q), .Q_N(~Q), .RESET_B(~R), .SET_B(~S));
Mapping DFF cells in module `\fulladder':

Executing OPT pass (performing simple optimizations).

5.1. Executing OPT_EXPR pass (perform const folding).
5.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
5.3. Executing OPT_MUXTREE pass (detect dead branches in mux trees).
Running muxtree optimizer on module \fulladder..
Creating internal representation of mux trees.
No muxes found in this module.
Removed 0 multiplexer ports.
5.4. Executing OPT_REDUCE pass (consolidate $mux and $reduce_ inputs).
Optimizing cells in module \fulladder.
Performed a total of 0 changes.
5.5. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\fulladder'.
Removed a total of 0 cells.
5.6. Executing OPT_RMDFF pass (remove dff with constant values).
5.7. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \fulladder..
5.8. Executing OPT_EXPR pass (perform const folding).
5.9. Finished OPT passes. (There is nothing left to do.)

Executing ABC pass (technology mapping using ABC).

6.1. Extracting gate netlist of module \fulladder' to /input.blif'..
Extracted 5 gates and 8 wires to a netlist network with 3 inputs and 2 outputs.
6.1.1. Executing ABC.
Running ABC command: /usr/local/share/qflow/bin/yosys-abc -s -f /abc.script 2>&1
ABC: ABC command line: "source /abc.script".
ABC:
ABC: + read_blif /input.blif
ABC: + read_lib -w /usr/share/pdk/sky130A/libs.ref/sky130_fd_sc_hs/lib/sky130_fd_sc_hs__ff_n40C_1v95.lib
ABC: Parsing finished successfully.  Parsing time =     1.36 sec
ABC: Scl_LibertyReadGenlib() skipped cell "sky130_fd_sc_hs__decap_4" without logic function.
ABC: Scl_LibertyReadGenlib() skipped cell "sky130_fd_sc_hs__decap_8" without logic function.
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfbbn_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfbbn_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfbbp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfrbp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfrbp_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfrtn_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfrtp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfrtp_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfrtp_4".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfsbp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfsbp_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfstp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfstp_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfstp_4".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfxbp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfxbp_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfxtp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfxtp_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dfxtp_4".
ABC: Scl_LibertyReadGenlib() skipped cell "sky130_fd_sc_hs__dlclkp_1" without logic function.
ABC: Scl_LibertyReadGenlib() skipped cell "sky130_fd_sc_hs__dlclkp_2" without logic function.
ABC: Scl_LibertyReadGenlib() skipped cell "sky130_fd_sc_hs__dlclkp_4" without logic function.
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrbn_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrbn_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrbp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrbp_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrtn_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrtn_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrtn_4".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrtp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrtp_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlrtp_4".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlxbn_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlxbn_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlxbp_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlxtn_1".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlxtn_2".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlxtn_4".
ABC: Scl_LibertyReadGenlib() skipped sequential cell "sky130_fd_sc_hs__dlxtp_1".
ABC: Scl_LibertyReadGenlib() skipped three-state cell "sky130_fd_sc_hs__ebufn_1".
ABC: Scl_LibertyReadGenlib() skipped three-state cell "sky130_fd_sc_hs__ebufn_2".
ABC: Scl_LibertyReadGenlib() skipped three-state cell "sky130_fd_sc_hs__ebufn_4".
ABC: Scl_LibertyReadGenlib() skipped three-state cell "sky130_fd_sc_hs__ebufn_8".
ABC: Scl_ERROR: ABC: execution of command "/usr/local/share/qflow/bin/yosys-abc -s -f /tmp/yosys-abc-jb9MQs/abc.script 2>&1" failed: return code 134.
outputprep failure:  No file fulladder_mapped.blif.
Premature exit.
Synthesis flow stopped due to error condition.

@buraktoker :  I think your main problem is that you're using qflow version 1.3 which is completely deprecated and unsupported.


Add soc-ci as command line interface to our CI

This is useful to answer some questions that I usually
have when I work with our CI system.

This is thre script I use for handling my usual CI tasks. I think there might be overlaps with other scripts but maybe it is still useful for others...