Splitting up the Raylib modules further (audio, textures, text)

Hello,
Thank you so much for the excellent Nim wrapper of raylib. One feature that I would like to request is for the modules to be split up closer to what Raylib itself offers. For example, splitting out raudio, textures, text, etc. My specific use case involves just playing audio, so I don't want to have to compile in all of the GUI/X11 related dependencies if possible.

Thank you for your kind words!
Regarding your request, do I understand correctly that you would like to link a separate raudio.c file with RAUDIO_STANDALONE option and use the header file just for this file?
As I can see from raudio.c file, the RAUDIO_STANDALONE does not modify the API and just modifies existing behaviors. So it should be possible to use it. Would that be possible for you to try the following:

Get that raudio.c file into the same src directory as your executable
At the top of your source file add something like {.compile: "raudio.c".}, as in example here
Compile your executable with -d:nimraylib_now_linkingOverride, as can be seen from here, this disables any attempts to link the files

My understanding is that you can use same header as raylib.h even if the implementation of the C file does not completely contain all declared functions. And that should mean that we can use same raylib.nim file here as well.
Let me know if you have any troubles with that.

Hm, I had to do that alone with pulling in many of the external header files that raudio uses and putting them in the correct directory. After doing that though, I ended up with the following error:
 error: incompatible types when assigning to type ‘AudioStream’ from type ‘int’
 1162 |             music.stream = LoadAudioStream(ctxWav->sampleRate, sampleSize, ctxWav->channels);

I changed some of the compile flags, now it looks like this:
nim c -r -d:nimraylib_now_linkingOverride --threads:on --passC:-DRAUDIO_STANDALONE
The current error is
/home/ajusa/Documents/ajmp/raudio.c: In function ‘LoadWave’:
/home/ajusa/Documents/ajmp/raudio.c:719:16: error: incompatible types when assigning to type ‘Wave’ from type ‘int’
  719 |         wave = LoadWaveFromMemory(GetFileExtension(fileName), fileData, fileSize);
      |                ^~~~~~~~~~~~~~~~~~
/home/ajusa/Documents/ajmp/raudio.c: At top level:
/home/ajusa/Documents/ajmp/raudio.c:728:6: error: conflicting types for ‘LoadWaveFromMemory’
  728 | Wave LoadWaveFromMemory(const char *fileType, const unsigned char *fileData, int dataSize)
      |      ^~~~~~~~~~~~~~~~~~
/home/ajusa/Documents/ajmp/raudio.c:719:16: note: previous implicit declaration of ‘LoadWaveFromMemory’ was here
  719 |         wave = LoadWaveFromMemory(GetFileExtension(fileName), fileData, fileSize);
      |                ^~~~~~~~~~~~~~~~~~
/home/ajusa/Documents/ajmp/raudio.c:838:6: error: conflicting types for ‘ExportWave’
  838 | bool ExportWave(Wave wave, const char *fileName)
      |      ^~~~~~~~~~
In file included from /home/ajusa/Documents/ajmp/raudio.c:69:
/usr/include/raudio.h:146:6: note: previous declaration of ‘ExportWave’ was here
  146 | void ExportWave(Wave wave, const char *fileName);               // Export wave data to file
      |      ^~~~~~~~~~
compilation terminated due to -fmax-errors=3.

My knowledge of C is pretty rusty, not really sure why this is causing an error.

Thank you for the attempts! It looks like it needs a lot more effort then. I'm a bit worried that this will grow too large since I already support 2 different versions of mangled/not mangled versions due to conflicting names on Windows machines. I should have free time in a week or two, I will take a look what could be sensible, it might be easy to do too.
About the dependencies, do I understand correctly that these were only the files listed here, or you had to do any additional chores?
And last question, do you plan to use it together with the whole Raylib or just as a single unit with no intention to use any other units from Raylib? I think in the output you provided happens exactly that, some conflicting files are included several times.

Sorry about that, I should have provided at least a bit more information:
My directory structure looks like this:
├── ajmp.nim
├── config.h
├── external
│   ├── dr_mp3.h
│   ├── dr_wav.h
│   ├── jar_mod.h
│   ├── jar_xm.h
│   ├── miniaudio.h
│   └── stb_vorbis.h
├── music.mp3
└── raudio.c

With ajmp.nim looking like this:
import os, nimraylib_now

{.compile: "raudio.c".}

initAudioDevice()      #  Initialize audio device

let music = loadMusicStream("music.mp3")         #  Load MP3 audio file
music.setMusicPitch(1)
playMusicStream(music)
while true:
   music.updateMusicStream()
   sleep(20)

And the command to compile is the same as above, nim c -r -d:nimraylib_now_linkingOverride --threads:on --passC:-DRAUDIO_STANDALONE ajmp.nim
So basically the only additional libraries I had to add (other than required dependencies) was config.h.
I plan on using this without any other parts of Raylib. I'm making a super small headless music player that suits my needs, so I shouldn't need any other Raylib modules.

Alright, thank you! Looks like it should be relatively easy to do, I will try to implement it in the nearest future.

@ajusa to give a heads up here. I didn't get to work on it as it appears a lot more complicated than just adding a few lines of code. The problem is that right now I support 2 separate ways of packaging raylib C library - by statically compiling it and by linking it dynamically. With support for separate modules this matrix splits yet again into more derivations which looks too complicated.
I think the right way is to drop dynamic linking and always compile statically. And then add ability to compile only specific parts of the raylib library instead of the whole package. I would like to hear your thoughts on this and whether you found any solution to this problem yet.
Dynamic linking looks as a less priority than separate packages from raylib. And I don't think I can afford to support it all.

Note to self: the raylib.h file can actually be fully substituted by its parts as shown in janet bindings https://github.com/janet-lang/jaylib/tree/master/src. The problem is that raylib.h is specifically tweaked to be easy to parse, other files will require special handling and probably contributions to the source. Currently we do specific parsing for raygui, raymath and physac - this is not a very pleasant experience.


NSLayoutConstraintNumberExceedsLimit

InfiniteLayout_Example[89608:25311340]
This NSLayoutConstraint is being configured with a constant that exceeds internal limits.  A smaller value will be substituted, but this problem should be fixed. Break on BOOL _NSLayoutConstraintNumberExceedsLimit(void) to debug.  This will be logged only once.  This may break in the future.

I found this problem when running example of custom layout

@arnauddorgans can you look at this please?
I'm having the same issue in my App, and it's driving me nuts!

@seenoevo have you found any solution for this. I am also facing the same issue in my app for a custom layout.

I'm not sure how to resolve the issue but I debugged it to this line inInfiniteCollectionView.swift
open override func layoutSubviews() {
super.layoutSubviews()  <------------------here
self.updateLayoutIfNeeded()
}


mod_auth_openidc.c: set r->ap_auth_type when handling auth

Apache expects mod_auth_* modules to populate r->ap_auth_type to server as the source of the AUTH_TYPE CGI variable. This allows content or other modules to detect the authentication source for the request. I applied the common idiom that can be found in mod_auth_basic and mod_auth_form, which is to save the result of ap_auth_type(r) to a variable and use that in the r->ap_auth_type assignment. But in mixed mode, it assigns r->ap_auth_type to whichever type is actually in use.
Testing

make test passes
Created a test conf:OIDCCryptoPassphrase ...
OIDCRedirectURI /oidctest/restricted/redirect
OIDCProviderMetadataURL https://accounts.google.com/.well-known/openid-configuration
OIDCClientID ...
OIDCClientSecret ...
OIDCScope "openid email profile"

<Directory /var/www/html/oidctest>
	AuthType auth-openidc
	Header set Cache-Control no-store
	Require valid-user
	Options +Includes
	AddType text/html .shtml
	AddOutputFilter INCLUDES .shtml
	DirectoryIndex index.shtml
</Directory>

Created a simple index.shtml:<!DOCTYPE html>
<title>Hello from index</title>

Hello from index

Your REMOTE_USER is ''.

Your AUTH_TYPE is ''.

Without this change, making a request to /oidctest/ results in this output:Your AUTH_TYPE is '(none)'.

With this change, making a request to /oidctest/ successfully populates AUTH_TYPE:Your AUTH_TYPE is 'openid-connect'.

I also verified the correct AUTH_TYPE when using AuthType openid-connect instead of mixed mode.

good stuff, thanks!


Tweaks due to engine update to v4.2.1-stable

The engine was updated to the newest v4.2.1 stable version. A few tweaks were needed to update the project.
Most notably, Tabs are now finally focusable, so our workaround is not needed anymore. While code was simplified there, it can't be removed entirely due to other behaviors.

It seems the CI suddenly is giving Wmaybe-unitialized errors our of a sudden. These are random between systems, and don't occur on Godot CI.
So, whatever, werror is no more ¯\_(ツ)_/¯


Add FinderMinder v1.2

FinderMinder by Irradiated Software
Signed-off-by: Daniel Bayley<EMAIL_ADDRESS>

There's an option to squash commits in Tower, but I think it can only be done when merging one branch into another. The homebrew-cask guidelines say to submit PRs from the new branch, so what to do?

Whatever you did, was correct.

@vitorgalvao Strangely i'm getting an Uh oh, could not identify primary container for '/Library/Caches/Homebrew/finderminder-latest.zip' error when doing brew install finderminder. What could be causing this?

url is wrong. It’s pointing to an html page. Correct link is http://www.irradiatedsoftware.com/download/FinderMinder.zip. Care to fix it?

Sure.

don’t forget to confirm the checksum

I used :no_check because the link doesn't contain a version number, and according to the docs;
This combination of version :latest and sha256 :no_check is currently the preferred mechanism when an unversioned download URL is available

I therefore shouldn't right?

You can’t fix it here since it has been merged; it needs to be a new PR.
Oh, right, I forgot this was a :no_check. In that case, only url needs changing. Don’t worry about it, I can do it faster, since I can commit directly from the web interface.

Already figured it out I think. See #11698


Challenge Fails: Waiting for HTTP-01 challenge propagation: did not get expected response when querying endpoint, expected 'XXXX'  but got: 'YYYY'

I am facing an issue in regards using cert-manager along with Kong Ingress Controller to automate TLS certificate provisioning.
When I am provisioning I get the following error: Waiting for HTTP-01 challenge propagation: did not get expected response when querying endpoint, expected 'xxxx' but got: Hostname: 'yyyy'
Followed this tutorial
Environment:

Kubernetes 1.17.11
Azure AKS
Kong ingress controller
Cert manager: Lets encrypt

Almost the same error for me except I use Nginx ingress controller 1.10.2.
When describing the Challenge, I get:
Waiting for HTTP-01 challenge propagation: did not get expected response when querying endpoint, expected "XXXX" but got: <!doctype html>
<html l... (truncated)

Do you also see this when you access the token URL on your computer?
Can you check if the created ingress resource is correct?

/triage support

Calling _http://mysite/.well-known/acme-challenge/CHALLENGE_KEY_ (as is described in the cert-manager generated ingress) from my computer brings me to my main web application, as it's configured in my own ingress.
I'll try to use acme.cert-manager.io/http01-edit-in-place: "true" to see if it works better.


Geo monitoring foreground service killed when app is closed

I noticed that when the app process is killed via the process manager the foreground service is removed from the android notification drawer. Is there a configuration setting that will allow the foreground service to run even if the main activity is killed?

That's a good question
On Sunday, January 18, 2015, reloaded<EMAIL_ADDRESS>wrote:

I noticed that when the app process is killed via the process manager the
foreground service is removed from the android notification drawer. Is
there a configuration setting that will allow the foreground service to run
even if the main activity is killed?
—
Reply to this email directly or view it on GitHub
https://github.com/christocracy/cordova-plugin-background-geolocation/issues/130
.

--
Snet from Gmail Mobile

So is this something you're going to look into?

I haven’t been inside the Android code in months, way too busy on other
projects.
I accept pull-requests if you care to dive in.
On Sun, Jan 18, 2015 at 11:38 PM, reloaded<EMAIL_ADDRESS>wrote:

So is this something you're going to look into?
—
Reply to this email directly or view it on GitHub
https://github.com/christocracy/cordova-plugin-background-geolocation/issues/130#issuecomment-70445688
.

--
Chris Scott
Transistor Software http://www.transistorsoft.com

Android has been refactored.

plugin no longer handles http; calls js callback (just like ios)
much improved battery efficiency.
no more foreground service

http://christocracy.github.io/cordova-background-geolocation/


MS Office "Share as link" feature not working properly

Hello,
I can't get to work the feature that allows to share a doc by email :
Sharepoint has a similar feature, and the link is formated as https://sharepoint.mydomain.com.
With WebDAVSharp.Server, I expect https://webdav.mydomain.com but I get
file:///\webdav.mydomain.com@SSL\DavWWWRoot\
this is a big problem because it implies the users to all have the same configuration on their PC.
Any workaround?
Thanks

Morning, I am currently using the webdav as a file server.  We mapped the \\DavWWWRoot<User Folder> to there network drives when they log in.  After doing this we had no problems with users using the server as a network share.  You have to be careful, windows will try and change the unc path to \server\path  and drop the DavWWWRoot.

Also, if you could post screenshot with what your talking about circled it would help me trace down the issue faster.  I have an idea that might fix it.

@benjlevesque and I communicated about this a while back, and he told me that adding a piece of SharePoint's header to the OPTIONS method worked.
In OPTIONS, adding the following code did the trick for him.
context.Response.AppendHeader("X-MSDAVEXT", "1");
context.Response.AppendHeader("DocumentManagementServer", "Properties Schema;");
context.Response.AppendHeader("X-MSFSSHTTP", "1.2");
var requestUri = GetRequestUri(context.Request.Url.ToString());
context.Response.AppendHeader("X-MSWEBURL", requestUri.AbsoluteUri);
context.Response.AppendHeader("DAV", "1,2");
context.Response.AppendHeader("Public-Extension", "http://schemas.microsoft.com/repl-2");

So he suggested to include an extension to the server, which is not in the RFC, in order to support Office.


Let curve inherit type of given rates for its methods

closes #107
Todo:

[ ] Test for all cases
[x] Bootstrap/simple curves
[ ] NS/NSS assume Float64 in the default parameters and aren't given a chance to see the Rates before constructing
[ ] Smith Wilson curves
[ ] document _value_type
[ ] Add doc section

Per M Abbot on slack:

A common pattern here is to make a 2nd type parameter, so that you can get the eltype in function signatures easily:
struct MyVec{T,A}
   values::A
   MyVec(x::A) where {A<:AbstractVector{T}} where T = new{T,A}(x)
end
MyVec([1,2,3])
fun(x::MyVec{T}) where T = T

instead of
struct MyVec{T}
   values::AbstractVector{T}
end


Wrong aggregation of Precision\Recall\F1-Score

🐛 Bug
I am training a binary classifier and am monitoring the following metrics: precision, recall, accuracy, F1 score.
During validation phase, the dataloader loads N batches where the samples all belong to class 0, and then M batches where the samples belong to class 1.
The aggregate accuracy that is calculated at the end of the epoch is identical to what I get from my script, while Precision and Recall are wrong.
This behaviour occurs for Precision, Recall, F1-Score, which have about half the value they should have: Accuracy 0.9 while these values have 0.55
I think the problem is due to the fact that the first N batches have Precision-Recall around 0 because they have no positive class samples, while the other M batches have around 1 because they only have positive class samples and when I aggregate these results I get a value of around 0.5.
I am monitoring these values with BinaryPrecision, BinaryRecall, BinaryF1Score.
Do you know what could be the problem? I think there is something strange in the aggregation of these metrics

Hi @silvanobianchi , thanks for reporting this issue.
This sound very strange to me. Regardless of how data is feed into the metrics, the correct result should still be calculated. Here is an example where all data is feed in as one batch vs. doing it over multiple batches. Also note that the labels are split in the way you describe:
import torch
from torchmetrics import MetricCollection
from torchmetrics.classification import BinaryPrecision, BinaryRecall, BinaryAccuracy

preds = torch.randint(2, (1000,))
target = torch.cat([torch.zeros(500), torch.ones(500)], dim=0)

# all as one batch
metrics = MetricCollection(BinaryAccuracy(), BinaryPrecision(), BinaryRecall())
print(metrics(preds, target))

# as separate batches
metrics = MetricCollection(BinaryAccuracy(), BinaryPrecision(), BinaryRecall())
for p, t in zip(preds.split(10), target.split(10)):
    metrics.update(p, t)
print(metrics.compute())

if you run the above it will output the exact same in both cases.


Support bindingType for called processes/decisions/forms

Problem you would like to solve
As a Camunda 8 user, when I design a BPMN process, I'd like to be able to choose between the binding types latest and deployment for called processes, called decisions and linked forms. I would also like to understand the differences between them so I can pick the right one for my use case.
Proposed solution

[ ] Add a new dropdown "Binding" with the options latest and deployment to the properties panel:

[ ] to the "Called element" section for a call activity
[ ] to the "Called decision" section for a business rule task (below "Decision ID")
[ ] to the "Form" section for a user task; the dropdown must only be displayed in the following cases (for the other ones, the binding type is not applicable):

implementation type: Zeebe user task + form type: Camunda Form
implementation type: Job Worker + form type: Camunda Form (linked)

[ ] Add a tooltip for the dropdown which explains the different options.

see suggested design and wording in: https://github.com/camunda/product-design/issues/1811

[ ] We validate the binding type using our usual infrastructure (https://github.com/camunda/camunda-modeler/issues/4386)

Implementation Notes

The binding type should be stored in the new attribute bindingType in the diagram's XML:<zeebe:calledElement processId="test-process" bindingType="deployment" ... />
<zeebe:calledDecision decisionId="test-decision" bindingType="deployment" ... />
<zeebe:formDefinition formId="test-form" bindingType="deployment" ... />

If the attribute is not set, select latest as the default option.

Alternatives considered
None.
Additional context

product hub epic: https://github.com/camunda/product-hub/issues/1920
implementation epic: https://github.com/camunda/camunda/issues/19384
relates to https://github.com/camunda/camunda-modeler/issues/4386

Thanks @jfriedenstab. Tagged for 8.6.
Following our normal procedures we'll work on this once the respective feature is merged in Zebee.

This is scheduled on the run-time side of things for 8.6-alpha4. Let's see if we can support it in the modelers at the same time.

Question: If the bindingType attribute is missing, is latest assumed?

@philippfromme Yes, exactly.

@philippfromme Yes, exactly.

Sorry, found it in the original issue. 😅

This is fixed upstream.


Hue Sync Box support?

Hue Sync Box (new HDMI) support:

Power Toggle the Sync Box
Switch to turn on and off (Start/Stop) light Syncing.

The basic function fro the iOS Hue Sync.app would be great.
I think Hue will be slow to develop Home.app integration for the HDMI Sync Box unfortunately. The two functions mention above are much needed as controllable switches in HomeKit.
Do you think you can add that to your plugin?

homebridge-hue already supports stopping syncing, since that’s supported by the (regular) Hue API, see #496.  I won’t be supporting the Hue entertainment API, which is required to start syncing.  I don’t even know if the HDMI box provides an API.

There seems to be an api, but I haven't figured out how to use it yet. There is also no documentation available an not even release note or something similar. Using https://[box ip]/api you get the following promising response:
serviceType":"huesync","deviceType":"HSB1","support":[{"version":1,"path":"/v1","level":3
Seems /api/v1 would be the way to go but you only get an "invalid token" message. No idea how to get one so far😑

@MadMonkey87
https://developers.meethue.com/philips-hue-can-become-a-natural-ingredient-of-any-gaming-movie-or-audio-experience-we-believe-that-lighting-can-provide-a-new-level-of-spacial-immersion-join-us/

@leoneleone that is the entertainment api the hue sync box is using and not an api to controll the box itself.

Here are some info about the Sync Box API based on my personal research.
The box serves a REST API on SSL (self-signed cert). Authentication is made with JSON Web Tokens (JWT). I'm still working on finding how to get a fresh token, but spoofing the token of my phone, i manage to get it work. Here are some basic info, more to come :

Operation
URL
Method
data
Variables

Get current state
/api/v1
GET

Change mode
/api/v1/execution
PUT
{   "mode": "MODE" }
MODE: passthrough | powersave | video |   music | game

Change brightness
/api/v1/execution
PUT
{  "brightness": 50 }
0 -> 200

Change intensity
/api/v1/execution
PUT
{ "MODE": { "intensity": "INTENSITY" } }
MODE: video | music | game   INTENSITY: subtle | moderate | high |   intense

Looks like the Sync Box might get native HomeKit support: https://www.macrumors.com/2020/01/07/philips-hue-new-outdoor-lights/.

https://developers.meethue.com/develop/hue-entertainment/hue-hdmi-sync-box-api/

https://developers.meethue.com/develop/hue-entertainment/hue-hdmi-sync-box-api/

Pretty cool, I've updated my library already. It is pretty much the same api as described here. In addition, the secret for the registration has been dropped and IR codes and presets have been addes


Compilation hangs on Scala 2 using fairly long twiddles

Hello!
When I tried upgrading Skunk to 0.6.0, which uses this library, I discovered that compilation would hang, whereas with the previous version (using the old twiddle lists), it was fairly fast.
Digging in a bit, it seemed to be caused by some queries that selected a fair amount of columns (20 or so). I isolated a minimum example to demonstrate the problem: this snippet currently makes the compilation hang using Scala 2.13.12
import org.typelevel.twiddles._

1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
EmptyTuple

Scastie
I suspect the implicit conversion hlistToTuple in TwiddleCompat is causing unnecessary failed implicit searches exhibiting a quadratic complexity somewhere (even though the exact mechanism is not clear to me, it seems to be constantly trying to build a Tupler).
In fact, removing the implicit from scope makes it compile again.
import org.typelevel.twiddles.{hlistToTuple => _, _}

1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
1 *: 1 *: 1 *: 1 *:
EmptyTuple

Scastie
An approach I tried which seems to preserve the tuple conversion and not make the compiler hang is to define an implicit conversion for every tuple arity, mirroring the already existing tupleNtoHlist functions.
E.g.:
implicit def hlistToTuple2[Z <: Tuple, A, B](z: Z)(implicit
    tupler: Tupler.Aux[Z, (A, B)]
): (A, B) = tupler(z)

// and so on up to 22

This seems to help the compiler know the implicit is useless to build an HList. Is it because the output type is more explicit? I'm not sure.
I was planning on opening a PR to address this issue, as it is currently blocking our upgrade to the latest version of Skunk at work. We could keep using the legacy twiddles, but they would cause quite a lot of deprecation warnings. I just wanted to check which approach would be best to take first.
Thanks!

Great find! The workaround seems reasonable to me.

@francesconero I released Skunk 0.6.2 with this fix.

Thanks!

From: Michael Pilquist @.>
Sent: Thursday, November 23, 2023 2:41:13 PM
To: typelevel/twiddles @.>
Cc: Francesco Nero @.>; Mention @.>
Subject: Re: [typelevel/twiddles] Compilation hangs on Scala 2 using fairly long twiddles (Issue #12)
@francesconerohttps://github.com/francesconero I released Skunk 0.6.2 with this fix.
—
Reply to this email directly, view it on GitHubhttps://github.com/typelevel/twiddles/issues/12#issuecomment-1824458361, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABC6D42XTUW7RAL4YTMW2TLYF5G7TAVCNFSM6AAAAAA7NHFCK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRUGQ2TQMZWGE.
You are receiving this because you were mentioned.Message ID: @.***>


Upgrade jinja2

The pinned jinja2 means that niworkflows now needs to pin markupsafe.
What is the overall process supposed to be for updating pins?

should be closed with 3.9 release


CHIP Certificate: Update Extension Encoding Format

Need to update certificate extension to match the spec. Specifically:
-- CHIP certificate extensions should be encoded as TLV List
-- Updated extension tags

PR: #6015

closed with #6015


Add/to or create an images table while calling make_magic_plots

@njarboe, this is done and seems to be working.  I made a modified program new_make_magic_plots.py that will create image records and combine them with an existing images table if one is available.  Otherwise, it will create a new images table.  I have tested on 10 or so contributions and everything seems to work as expected, but we will probably find some more errors running it on the server.   If you can run it without replacing the existing plots, that might be best!

Plots have been running. Should be done this evening or tomorrow.

Found a bug in my code and needed to restart. I'll let you know when it's done.

Sounds good — I will expect to work on any errors found on Monday.

On Jun 21, 2019, at 10:07 AM, njarboe<EMAIL_ADDRESS>wrote:
Found a bug in my code and needed to restart. I'll let you know when it's done.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/352?email_source=notifications&email_token=AAOAMISTVNIEF3TQ2INCAIDP3UDG5A5CNFSM4FAAY4T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYJA7QQ#issuecomment-504500162, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOAMITZKC3VUP4VUGHJ65TP3UDG5ANCNFSM4FAAY4TQ.

The plots are done and the log is at http://<IP_ADDRESS>/plots/batchPlotsLog.txt
I saw only 4 Traceback errors. You can see the other files created in the plots/$MAGICID directories.

@ltauxe, you could check my fix for dayplot_magic in commit https://github.com/PmagPy/PmagPy/commit/bf0ab2936d38433733c816ad1c5dd2ee2023979c.
I was getting an error with contribution 14743 where the Bc list had no data and caused an error.  I just did the simplest possible fix but maybe some deeper logic should be used/fixed.

@njarboe, I fixed the two issues I found in the log.  Today is my last day of work for a while -- feel free to use the new_make_magic_plots if you want as it seems to be working!  I may also be available for small fixes here and there.

it seems to work as advertised.
lisa

On Jun 26, 2019, at 1:15 PM, Lori J<EMAIL_ADDRESS>wrote:
@ltauxe https://github.com/ltauxe, you could check my fix for dayplot_magic in commit bf0ab29 https://github.com/PmagPy/PmagPy/commit/bf0ab2936d38433733c816ad1c5dd2ee2023979c.
I was getting an error with contribution 14743 https://earthref.org/MagIC/14743 where the Bc list had no data and caused an error. I just did the simplest possible fix but maybe some deeper logic should be used/fixed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/352?email_source=notifications&email_token=AABKWDLHQOG3ELALRNQU43DP4PE5TA5CNFSM4FAAY4T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUV7RA#issuecomment-506027972, or mute the thread https://github.com/notifications/unsubscribe-auth/AABKWDNO6RUUQOI5JUR7HBLP4PE5TANCNFSM4FAAY4TQ.

@njarboe, are you using new_make_magic_plots.py currently on the server?

Once #602 is solved, I will rename new_make_magic_plots to make_magic_plots and get rid of the old make_magic_plots.

I've renamed new_make_magic_plots --> make_magic_plots and removed the old version.

Changed server programs to use make_magic_plots again.


Fix EventCard ComponentWillMount Warning

When running tests or in the browser on localhost:3000/events, we see this warning:

Track down the issue (it is likely the Ionicon component here)
The solution
If it is the Ionicon component, you can do one of two things:

Try to update the ionicon dependency like this
Remove the Ionicon component.

If you decide to remove Ionicon component, render the icon as an svg and store the svg in this file.

I recommend removing the Ionicon library as standalone SVG's are lightweight and easy to create. You can use a library like:
https://materialdesignicons.com/
https://iconsvg.xyz/?utm_campaign=bizarrodevs&utm_medium=email&utm_source=BizarroDevs_82
https://www.svgbackgrounds.com/
a chrome extension such as: https://chrome.google.com/webstore/detail/icomoon/kppingdhhalimbaehfmhldppemnmlcjd?hl=en
Otherwise you can generate your own files through Illustrator and free alternatives and then use a compression service to compress the generated SVG files. A quick google search for online compression for SVGs is all you need

3/4/20
Use this svg file to add the clock and map pin

3/4/20
Use this svg file to add the clock and map pin
Just use inspect element on the icon and copy and paste the HTML into the above file

I added the HTML code of the SVG file into the SVG file above.


Implementation of the Gray-Synth and Patel–Markov–Hayes algorithms

Summary
I added an implementation of the Gray-Synth algorithm [1] and the Patel–Markov–Hayes algorithm [2]
Details and comments
Hello again,
my name is Samuel Bosch, and I am a master's student at EPFL in Switzerland. I work in the group of Prof. Giovanni de Micheli on Quantum Computing. My supervisors are Dr. Mathias Soeken and Bruno Schmitt. I started programming in Qiskit quite recently and would like to make my second contribution to Qiskit-Terra.
The implementation of the Gray-Synth algorithm is explained in detail in reference [1] in section 4. The code of the algorithm is based on the pseudo-code named "Algorithm 1. Algorithm for synthesizing a parity network".
The implementation of the Patel–Markov–Hayes algorithm (which is needed in the Gray-Synth algorithm) can be found in reference [2]. The code of the algorithm is based on the pseudo-code named "Algorithm 1: C-NOT Circuit Synthesis".
I wasn't really sure where to put my code, so I put it under "qiskit-terra ▸ qiskit ▸ transpiler ▸ passes", which might not be the optimal location. Let me know if there is anything I can change in the code.
Best regards,
Samuel

[1] Amy, Matthew, Parsiad Azimzadeh, and Michele Mosca. "On the controlled-NOT complexity of controlled-NOT–phase circuits." Quantum Science and Technology 4.1 (2018): 015002.

[2] Patel, Ketan N., Igor L. Markov, and John P. Hayes. "Optimal synthesis of linear reversible circuits." Quantum Information & Computation 8.3 (2008): 282-294.

I am receiving the following error and don't know what to do about it:
test/python/transpiler/test_graysynth.py:89:8: E1101: Instance of 'TestGraySynth' has no 'assertTrue' member (no-member)
Could someone help me out with this? Thank you!

Hi @BoschSamuel, thank you for your recent contributions! We will try to review them as soon as possible.
About the error you are getting here, you have to do this:
from qiskit.test import QiskitTestCase

 class TestGraySynth(QiskitTestCase):
    ...

I am also not sure why the "cyclic-import" error occurs. When I run make style && make lint on my computer, this doesn't happen.

@boschmitt I had to read the GraySynth and Patel-Markov-Hayes algorithms in detail in order to review this, so it took me a bit of time. But I think it is ready now.
I made some changes. The commit history should be descriptive, but here is the gist:

added a couple more tests, mostly using the examples in the original papers
in adding tests, I found a bug in the cnot_synth algorithm, which I fixed in https://github.com/Qiskit/qiskit-terra/pull/2457/commits/9762a506b509f30d1d7681483ab44382faf56dff
I made some API changes for user-friendliness. In particular, I made the cnot_synth method standalone and not just an extension of graysynth. I also removed some unnecessary args (like number, which could just be inferred), and gave a default of 2 to the n_sections arg.
some docstring/cosmetic updates

One thing I wasn't able to reproduce from the paper is the example of doubly-controlled Z rotation in Figure 3.
A 6-cnot construction should be found according to the paper:

but here a 7-cnot construction is found:

Code for the above:
from qiskit.transpiler.synthesis import graysynth
cnots = [[1, 0, 1, 0, 1, 1, 0],
         [0, 1, 0, 1, 1, 1, 0],
         [0, 0, 1, 1, 1, 0, 1]]
angles = [1/8, 1/8, 3/8, 3/8, 1/8, 3/8, 1/8]
c_gray = graysynth(cnots, angles, 3)
c_gray.draw(output='mpl')

@ajavadia Thank you for the detailed review. I will work on this as soon as possible, as things are a bit crazy for me this and next week :)

This looks good to me now, thanks for the effort! I'll open an issue about that double-controlled Z synthesis to be investigated further.


err pull image from private image registry(harbor)

Expected Behavior
pull image sucess
Actual Behavior
Failed to pull image "hub.docker.dev.": rpc error: code = Unknown desc = Error response from daemon: pull access denied for hub.docker.dev. repository does not exist or may require 'docker login'
Steps to Reproduce the Problem

TaskRun yaml
config image: hub.docker.dev.**** (private registry)

Additional Info

Kubernetes version:

0.16.0
Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:27:17Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

Tekton Pipeline version:
Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

v0.18.0

err pull image from private image registry

I think this is not kind of bug.  We met the same problem when using it.
step1.create an serviceaccount in the namespace that your task runs.
step2.create an secret that save the username and password to the private image registry
step3.patch the secret to the serviceaccount   using command  like  "kubectl patch serviceaccount  serviceaccountname -p "{"imagePullSecrets":["name":"secretname"]}"  -n  namespace"
with the step1-3   the serviceaccount have the authority to pull image from your private image registry
step4 .add the "serviceaccount" property in the TASK YAML
Hope this solution can help.

This doc might also be helpful https://github.com/tektoncd/pipeline/blob/main/DEVELOPMENT.md#configure-container-registry

same issue here.
not able to pull image from private harbor registry.
I already created secret and attached it to the service account.
is there any additional settings need to be done for harbor registry?
Its working with normal pod by using imagepullsecret. which means my password is correct.
i am also able to use public images in the task from the same registry.so my url is also correct.
this is the error i got while try to pull image by the task.
ErrImagePull (rpc error: code = Unknown desc = failed to pull and unpack image "harbor.xxxxx.com/tekton-test/tekton-test:gitclone": failed to resolve reference "harbor.xxxxx.com/tekton-test/tekton-test:gitclone": pulling from host harbor.xxxxx.com failed with status code [manifests gitclone]: 401 Unauthorized)
do u guys have any idea about this error?
is there any change need to be done to the secret's annotation "tekton.dev/docker-0" ?
is there any way to directly attach the imagepullsecret in task itself ?

I had the same problem even if I followed the official documentation: https://tekton.dev/docs/pipelines/auth/#configuring-docker-authentication-for-docker
In the end, I found out that in serviceaccount.yaml, we should use imagePullSecrets instead of secrets.
here's the correct serviceaccount.yaml to make it works.
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-bot
imagePullSecrets:
  - name: YOUR_SECRET_NAME_HOLD_DOCKER_CONFIG

you may refer to kubernetes documentation: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-image-pull-secret-to-service-account

I had the same problem even if I followed the official documentation: https://tekton.dev/docs/pipelines/auth/#configuring-docker-authentication-for-docker
In the end, I found out that in serviceaccount.yaml, we should use imagePullSecrets instead of secrets. here's the correct serviceaccount.yaml to make it works.
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-bot
imagePullSecrets:
  - name: YOUR_SECRET_NAME_HOLD_DOCKER_CONFIG

you may refer to kubernetes documentation: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-image-pull-secret-to-service-account

It worked for me.
How strange!! How can they write such a big mistake in the Tekton docs. It wasted lots of my time.
Many thanks @crossRT for your help.

@crossRT @ashugcet 👋🏼 . As commented on the pull-request you sent, it's not a mistake, it is a different "feature" altogether. In your case, you want the node where the Pod created by the TaskRun to be able to pull from a private registry — and for this, the usual kubernetes way applies (because, it's kubernetes, we build on top).
The documentation you linked (https://tekton.dev/docs/pipelines/auth/#configuring-docker-authentication-for-docker), is not about that, but how to give the process in the Pod created by the TaskRun the docker configuration/credentials it will need to communicate with a private registry (to pull images using podman, or to push to a registry with kaniko, or to do other oci image manipulation with skopeo or something). Reading the doc, there is the following:

In the example below, before executing any Steps in the Run, Tekton creates a ~/.docker/config.json file containing the credentials specified in the Secret.

It's probably clear enough that it creates the file in the Pod and has nothing to do with the Node.
On that note, one of the reason why those are 2 differents reasons/feature/mechanisms, is because, in kubernetes there is a clear separation between the Node and the Pod. Allowing the Node to pull from a private registry, doesn't give any permission/credentials/… to a Pod running on it, to also pull the same thing — it's "isolated", it needs its own configuration.

It's probably clear enough that it creates the file in the Pod and has nothing to do with the Node.

Understood. Thanks for the clarification.


On dataset

Very nice work. The file datasets.zip of the dataset I downloaded is very small, only 134B. Can you provide the dataset through the network disk?

Thank you for your interest in our work. Please download the dataset
through this link:
https://github.com/fukangl/SMG-multimodal-grasping/blob/main/datasets.zip
If you encounter any issues, please let us know.
On Thu, May 11, 2023 at 9:22 PM YinfengYu @.***> wrote:

Very nice work. The file datasets.zip of the dataset I downloaded is very
small, only 134B. Can you provide the dataset through the network disk?
—
Reply to this email directly, view it on GitHub
https://github.com/fukangl/SMG-multimodal-grasping/issues/3, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AQIE5BEQKF5T3P5XALVLYP3XFWGHDANCNFSM6AAAAAAX63RN4Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@fukangl Thank you!


Don't require Store in Instance constructor

This can be inferred from the Module argument. Additionally add a
store accessor to an Instance in case it's needed to instantiate
another Module.
cc #708

It looks like the wasmtime proc macro codegen needs updating?

Oops, always forget those... Should be updated now!

Now down to just the unit test in src/callable.rs.

Ok, should be updated, and maybe even passing tests this time!


Transpile Examples

I downloaded the sample files and created a "new project" with them.
But i can not build it, because the stagexl_X dependencies time out ...
So i copied the video_example to a new project and uncommented the stagexl_X dependencies from the yaml.
But the transpiled index.dart.js has 230K - and http://www.stagexl.org/samples/video/index.dart.js only has 80K.
Do you have any hints on what the difference might be?

I just downloaded the index.dart.js file and it is 223KB in size, where do you see the 80KB file? Do you get the timeout when you do "Pub get" or "Pup upgrade" ? If this is the case you should check what's wrong with Pub.

Ah - maybe you see the 80K file because it is compressed with GZIP. The file is stored as compressed file on the server, when a browser downloads it, it will automatically uncompressed and you get the javascript file.

Ah OK! Didn't think of the GZIP - sorry - only checked the Net-"console" and got shocked by my 230K ... THANKS!
Yes - something wrong with Pub, i guess ... Both timeout (today)  ...
Downloading stagexl_spine 0.4.0...
Timed out after 30.0s while downloading https://pub.dartlang.org/packages/stagexl_spine/versions/0.4.0.tar.gz.
This is likely a transient error. Please try again later.
package:pub/src/io.dart 831  timeout.<fn>
dart:isolate                 _RawReceivePortImpl._handleMessage
This is an unexpected error. Please run

    pub --trace upgrade

and include the results in a bug report on http://dartbug.com/new.

Trace is
ERR : Timed out after 30.0s while downloading https://pub.dartlang.org/packages/stagexl_spine/versions/0.4.0.tar.gz.
    | This is likely a transient error. Please try again later.
FINE: Exception type: TimeoutException
ERR : package:pub/src/io.dart 831  timeout.<fn>
    | dart:isolate                 _RawReceivePortImpl._handleMessage
    | ===== asynchronous gap ===========================
    | dart:async                              Timer.Timer
    | package:pub/src/io.dart 820             timeout
    | package:pub/src/source/hosted.dart 194  HostedSource._download.<fn>.<fn>
    | dart:isolate                            _RawReceivePortImpl._handleMessage
    | ===== asynchronous gap ===========================
    | dart:async                              _Future.then
    | package:pub/src/source/hosted.dart 193  HostedSource._download.<fn>
    | dart:async                              Future.Future.sync
    | package:pub/src/source/hosted.dart 184  HostedSource._download
    | package:pub/src/source/hosted.dart 93   HostedSource.downloadToSystemCache.<fn>
    | dart:isolate                            _RawReceivePortImpl._handleMessage
    | ===== asynchronous gap ===========================
    | dart:async                             _Future.then
    | package:pub/src/source/hosted.dart 86  HostedSource.downloadToSystemCache
    | package:pub/src/source/cached.dart 51  CachedSource.get
    | package:pub/src/entrypoint.dart 365    Entrypoint._get.<fn>
    | dart:async                             Future.Future.sync
    | package:pub/src/entrypoint.dart 357    Entrypoint._get
    | dart:async                             Future.wait
    | package:pub/src/entrypoint.dart 133    Entrypoint.acquireDependencies.<async>
    | dart:isolate                           _RawReceivePortImpl._handleMessage
    | ===== asynchronous gap ===========================
    | dart:async                           _Future.then
    | package:pub/src/entrypoint.dart 115  Entrypoint.acquireDependencies.<async>
    | dart:isolate                         _RawReceivePortImpl._handleMessage
    | ===== asynchronous gap ===========================
    | dart:async                               Future.Future.microtask
    | package:pub/src/entrypoint.dart          Entrypoint.acquireDependencies
    | package:pub/src/command/upgrade.dart 34  UpgradeCommand.run.<async>
    | dart:isolate                             _RawReceivePortImpl._handleMessage
    | ===== asynchronous gap ===========================
    | dart:async                               Future.Future.microtask
    | package:pub/src/command/upgrade.dart     UpgradeCommand.run
    | package:args/command_runner.dart 178     CommandRunner.runCommand.<fn>
    | dart:async                               Future.Future.sync
    | package:args/command_runner.dart 131     CommandRunner.runCommand
    | package:pub/src/command_runner.dart 121  PubCommandRunner.runCommand.<async>.<fn>
    | dart:async                               Future.Future.sync
    | package:pub/src/utils.dart 103           captureErrors.<fn>
    | package:stack_trace/src/chain.dart 78    Chain.capture
    | package:pub/src/utils.dart 117           captureErrors
    | package:pub/src/command_runner.dart 121  PubCommandRunner.runCommand.<async>
    | dart:isolate                             _RawReceivePortImpl._handleMessage
---- End log transcript ----

Yes looks like a problem with Pub. When i download the file now it is fast. But still the StageXL_Spine file is pretty big (8.8MB). Maybe i should remove some of the samples in the next release or make them smaller :)

Hm - i have a very slow internet connection ... downloading takes a little bit > 30sec ... but Pub can't seriously mean that by "time out"???

No I don't think so. Probably just a temporary problem with the pub servers.

https://github.com/dart-lang/sdk/issues/23833#issuecomment-120804148

Thanks for opening the issue. It is really strange that pub has this strange timeout behavior.
Btw. totally unrelated to this issue ... It's interesting to know that Dart does not transpile to JavaScript.  But Dart is much more clever! In fact it's a real compilation with many optimizations like inlining, dead code elimination (tree shaking), loop optimizations etc. I just say that because it is an important difference if you explain Dart to other people and want to highlight the difference to TypeScript.

I agree - the timeout behavior seems pretty unlogical ...
And thanks for pointing this out! You are right of course.
PHPStorm calls it transpiling ... that's why i made this mistake ..
I read in the FAQs, that Dart strives to to generate small JS output. I am sure, the compiler does great work in doing this, but it is also worth noting, that the basic overhead seems to be relatively big - so using it for small web applications is questionable ... (see the 223K for the videoplayer ...)

And it does not support IE9 ... but there are still a lot of big companies (at least in Austria) using IE9 ...

Yes my company is supporting a web based administration tool which was developed for IE 7, it's a shame to tell customers that they have to use IE or "IE Tab" in Chrome. Btw. where are you located in Austria?

ouch ;)
Vienna ...


Record counts are sometimes 0 on the provider overview page

Note that Harvard & Columbia show 0 total and unique records despite having records in their streams:

Still seeing 0 counts:


feat: add quic server class

Pull Request Checklist
Please check if your pull request fulfills the following requirements:

[x] The commit message follows our guidelines: https://gitlab.playpod.ir/alpha/backend/server-services-next/-/blob/main/CONTRIBUTING.md#commit-message-format
[x] Tests for the changes have been added / updated (for feat / fix / refactor)
[x] Docs for the changes have been added / updated (for feat / fix / refactor)

Pull Request Type
What kind of change does this pull request introduce?

[ ] Build: Changes that affect the build system or external dependencies
[ ] CD: Changes to our CD configuration files and scripts
[ ] CI: Changes to our CI configuration files and scripts
[ ] Docs: Documentation only changes
[x] Feat: A new feature
[ ] Fix: A bug fix
[ ] Perf: A code change that improves performance
[ ] Refactor: A code change that neither fixes a bug nor adds a feature
[ ] Test: Adding missing tests or correcting existing tests

What is the current behavior?

Issue #483
What is the new behavior?

simplified making a server with a helper class named w_quic_server.

Does this Pull Request introduce a breaking change?

[ ] Yes
[x] No

Other information
Closes #483

@cthulhu-irl thank you


Document nixos-rebuild

A man page and/or --help output would be nice.

I'm confused. nixos-rebuild already has a man page, and --help opens it.

Corrected that to nixos-version


Project Charter Documentation(01)

Purpose of preparing the study guide -WHY?
Success Criteria -WHAT?

Reviewed


dropdown list item for nav bar not linking to other pages

Bug reports must include a live demo of the issue. Per our contributing guidelines, please create a reduced test case via CodePen or JS Bin and report back with your link, Bootstrap version, and specific browser and operating system details.

This is a saved reply.

I have created a reduced test case here:
https://codepen.io/aubreysine/pen/qBVJwaX
https://urldefense.com/v3/__https://codepen.io/aubreysine/pen/qBVJwaX__;!!NCc8flgU!NjEQWU4f8f7A_1Q9oouQHw6_H7iaGtjNa6Nc2AY13yG2bsNaLzCmItJqC9S5$
.
The issue is that the dropdown menu item will not redirect to other pages
of the website. I can only reference other areas inside the given HTML
file.
Aubrey Sine  *
Solutions Architect
https://segment.com/
EMAIL @.**
On Wed, Jan 26, 2022 at 9:11 AM Gaël Poupard @.***>
wrote:

Closed #35728
https://urldefense.com/v3/__https://github.com/twbs/bootstrap/issues/35728__;!!NCc8flgU!MjlctJkgCjcyR96IeaLoTVMl3MV-xCCNCPmE4mcoB9wUuRa59D7-l65sLu41$
.
—
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/twbs/bootstrap/issues/35728*event-5958214449__;Iw!!NCc8flgU!MjlctJkgCjcyR96IeaLoTVMl3MV-xCCNCPmE4mcoB9wUuRa59D7-l6G0Uave$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AWUGH6EUNXSFTOCCL2GY4UDUYATH3ANCNFSM5M3Q2ZPA__;!!NCc8flgU!MjlctJkgCjcyR96IeaLoTVMl3MV-xCCNCPmE4mcoB9wUuRa59D7-lwW2jXVG$
.
Triage notifications on the go with GitHub Mobile for iOS
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!NCc8flgU!MjlctJkgCjcyR96IeaLoTVMl3MV-xCCNCPmE4mcoB9wUuRa59D7-lxgMLk4F$
or Android
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!NCc8flgU!MjlctJkgCjcyR96IeaLoTVMl3MV-xCCNCPmE4mcoB9wUuRa59D7-l-FAD0Y3$.
You are receiving this because you authored the thread.Message ID:
@.***>


Make in LXPLUS is failing

In gitlab by @mvicente on Jul 28, 2017, 10:57
I have a clean new folder with the latest version cloned.
I run the etc/scripts.setup_lxplus.sh, go to the build folder, "cmake .." and finally "make install -j16".
This is the output that I have.
Scanning dependencies of target AllpixObjects
[ 13%] Building CXX object src/objects/CMakeFiles/AllpixObjects.dir/Object.cpp.o
[ 15%] Building CXX object src/objects/CMakeFiles/AllpixObjects.dir/Pixel.cpp.o
[ 18%] Building CXX object src/objects/CMakeFiles/AllpixObjects.dir/MCParticle.cpp.o
[ 19%] Building CXX object src/objects/CMakeFiles/AllpixObjects.dir/PixelCharge.cpp.o
[ 19%] Building CXX object src/objects/CMakeFiles/AllpixObjects.dir/SensorCharge.cpp.o
[ 19%] Building CXX object src/objects/CMakeFiles/AllpixObjects.dir/DepositedCharge.cpp.o
[ 19%] Building CXX object src/objects/CMakeFiles/AllpixObjects.dir/PropagatedCharge.cpp.o
[ 19%] Building CXX object src/objects/CMakeFiles/AllpixObjects.dir/PixelHit.cpp.o
[ 21%] Linking CXX shared library libAllpixObjects.so
[ 21%] Built target AllpixObjects
Scanning dependencies of target AllpixCore
[ 23%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/utils/unit.cpp.o
[ 23%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/utils/log.cpp.o
[ 27%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/messenger/Messenger.cpp.o
[ 30%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/module/Module.cpp.o
[ 30%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/config/Configuration.cpp.o
[ 30%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/config/ConfigManager.cpp.o
[ 34%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/AllPix.cpp.o
[ 34%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/config/ConfigReader.cpp.o
[ 38%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/messenger/Message.cpp.o
[ 38%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/geometry/GeometryManager.cpp.o
[ 38%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/module/ModuleManager.cpp.o
[ 38%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/config/exceptions.cpp.o
[ 38%] Building CXX object src/core/CMakeFiles/AllpixCore.dir/geometry/Detector.cpp.o
[ 39%] Linking CXX executable dfise_converter
[ 39%] Built target dfise_converter
[ 40%] Linking CXX shared library libAllpixCore.so
[ 40%] Built target AllpixCore
Scanning dependencies of target AllpixModuleDefaultDigitizer
Scanning dependencies of target AllpixModuleElectricFieldReader
Scanning dependencies of target AllpixModuleDummy
Scanning dependencies of target AllpixModuleVisualizationGeant4
Scanning dependencies of target AllpixModuleDepositionGeant4
Scanning dependencies of target AllpixModuleGeometryBuilderTGeo
Scanning dependencies of target AllpixModuleGeometryBuilderGeant4
Scanning dependencies of target AllpixModuleROOTObjectReader
Scanning dependencies of target AllpixModuleROOTObjectWriter
Scanning dependencies of target AllpixModuleDetectorHistogrammer
Scanning dependencies of target AllpixModuleGenericPropagation
Scanning dependencies of target AllpixModuleRCEWriter
Scanning dependencies of target AllpixModuleSimpleTransfer
[ 42%] Building CXX object src/modules/ElectricFieldReader/CMakeFiles/AllpixModuleElectricFieldReader.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 46%] Building CXX object src/modules/ElectricFieldReader/CMakeFiles/AllpixModuleElectricFieldReader.dir/ElectricFieldReaderModule.cpp.o
[ 46%] Building CXX object src/modules/Dummy/CMakeFiles/AllpixModuleDummy.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 46%] Building CXX object src/modules/Dummy/CMakeFiles/AllpixModuleDummy.dir/DummyModule.cpp.o
[ 47%] Building CXX object src/modules/GeometryBuilderTGeo/CMakeFiles/AllpixModuleGeometryBuilderTGeo.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 48%] Building CXX object src/modules/DetectorHistogrammer/CMakeFiles/AllpixModuleDetectorHistogrammer.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 50%] Building CXX object src/modules/SimpleTransfer/CMakeFiles/AllpixModuleSimpleTransfer.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 51%] Building CXX object src/modules/DefaultDigitizer/CMakeFiles/AllpixModuleDefaultDigitizer.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 52%] Building CXX object src/modules/GeometryBuilderTGeo/CMakeFiles/AllpixModuleGeometryBuilderTGeo.dir/GeometryBuilderTGeoModule.cpp.o
clang-4.0: error: unable to execute command: No such file or directory
clang-4.0: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 4.0.0 (tags/RELEASE_400/final 302922)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /cvmfs/clicdp.cern.ch/compilers/llvm/4.0.0/x86_64-slc6/bin
clang-4.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
[ 55%] Building CXX object src/modules/RCEWriter/CMakeFiles/AllpixModuleRCEWriter.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 55%] Building CXX object src/modules/ROOTObjectWriter/CMakeFiles/AllpixModuleROOTObjectWriter.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 56%] Building CXX object src/modules/ROOTObjectReader/CMakeFiles/AllpixModuleROOTObjectReader.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 57%] Building CXX object src/modules/GenericPropagation/CMakeFiles/AllpixModuleGenericPropagation.dir/__/__/core/module/dynamic_module_impl.cpp.o
clang-4.0: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /tmp/mvicente/dynamic_module_impl-70ddcb.cpp
clang-4.0: note: diagnostic msg: /tmp/mvicente/dynamic_module_impl-70ddcb.sh
clang-4.0: note: diagnostic msg:

********************
make[2]: *** [src/modules/ElectricFieldReader/CMakeFiles/AllpixModuleElectricFieldReader.dir/__/__/core/module/dynamic_module_impl.cpp.o] Error 255
make[2]: *** Waiting for unfinished jobs....
[ 59%] Building CXX object src/modules/ROOTObjectReader/CMakeFiles/AllpixModuleROOTObjectReader.dir/ROOTObjectReaderModule.cpp.o
[ 60%] Building CXX object src/modules/DepositionGeant4/CMakeFiles/AllpixModuleDepositionGeant4.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 61%] Building CXX object src/modules/VisualizationGeant4/CMakeFiles/AllpixModuleVisualizationGeant4.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 63%] Building CXX object src/modules/ROOTObjectWriter/CMakeFiles/AllpixModuleROOTObjectWriter.dir/ROOTObjectWriterModule.cpp.o
[ 64%] Building CXX object src/modules/RCEWriter/CMakeFiles/AllpixModuleRCEWriter.dir/RCEWriterModule.cpp.o
[ 65%] Building CXX object src/modules/GenericPropagation/CMakeFiles/AllpixModuleGenericPropagation.dir/GenericPropagationModule.cpp.o
[ 68%] Building CXX object src/modules/VisualizationGeant4/CMakeFiles/AllpixModuleVisualizationGeant4.dir/VisualizationGeant4Module.cpp.o
[ 68%] Building CXX object src/modules/DetectorHistogrammer/CMakeFiles/AllpixModuleDetectorHistogrammer.dir/DetectorHistogrammerModule.cpp.o
[ 69%] Building CXX object src/modules/SimpleTransfer/CMakeFiles/AllpixModuleSimpleTransfer.dir/SimpleTransferModule.cpp.o
[ 71%] Building CXX object src/modules/DepositionGeant4/CMakeFiles/AllpixModuleDepositionGeant4.dir/DepositionGeant4Module.cpp.o
[ 73%] Building CXX object src/modules/DefaultDigitizer/CMakeFiles/AllpixModuleDefaultDigitizer.dir/DefaultDigitizerModule.cpp.o
[ 73%] Building CXX object src/modules/DepositionGeant4/CMakeFiles/AllpixModuleDepositionGeant4.dir/GeneratorActionG4.cpp.o
[ 75%] Linking CXX shared library libAllpixModuleDummy.so
[ 76%] Building CXX object src/modules/DepositionGeant4/CMakeFiles/AllpixModuleDepositionGeant4.dir/SensitiveDetectorActionG4.cpp.o
[ 76%] Built target AllpixModuleDummy
[ 77%] Building CXX object src/modules/GeometryBuilderGeant4/CMakeFiles/AllpixModuleGeometryBuilderGeant4.dir/__/__/core/module/dynamic_module_impl.cpp.o
[ 78%] Building CXX object src/modules/GeometryBuilderGeant4/CMakeFiles/AllpixModuleGeometryBuilderGeant4.dir/GeometryBuilderGeant4Module.cpp.o
[ 80%] Building CXX object src/modules/GeometryBuilderGeant4/CMakeFiles/AllpixModuleGeometryBuilderGeant4.dir/GeometryConstructionG4.cpp.o
[ 81%] Linking CXX shared library libAllpixModuleGeometryBuilderTGeo.so
make[1]: *** [src/modules/ElectricFieldReader/CMakeFiles/AllpixModuleElectricFieldReader.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 82%] Building CXX object src/modules/GeometryBuilderGeant4/CMakeFiles/AllpixModuleGeometryBuilderGeant4.dir/Parameterization2DG4.cpp.o
[ 84%] Linking CXX shared library libAllpixModuleDetectorHistogrammer.so
[ 84%] Built target AllpixModuleGeometryBuilderTGeo
[ 84%] Built target AllpixModuleDetectorHistogrammer
[ 85%] Linking CXX shared library libAllpixModuleRCEWriter.so
[ 86%] Linking CXX shared library libAllpixModuleROOTObjectReader.so
[ 88%] Linking CXX shared library libAllpixModuleDefaultDigitizer.so
[ 88%] Built target AllpixModuleRCEWriter
[ 89%] Linking CXX shared library libAllpixModuleSimpleTransfer.so
[ 89%] Built target AllpixModuleDefaultDigitizer
[ 89%] Built target AllpixModuleROOTObjectReader
[ 89%] Built target AllpixModuleSimpleTransfer
[ 90%] Linking CXX shared library libAllpixModuleROOTObjectWriter.so
[ 90%] Built target AllpixModuleROOTObjectWriter
[ 92%] Linking CXX shared library libAllpixModuleDepositionGeant4.so
[ 93%] Linking CXX shared library libAllpixModuleVisualizationGeant4.so
[ 93%] Built target AllpixModuleVisualizationGeant4
[ 93%] Built target AllpixModuleDepositionGeant4
[ 94%] Linking CXX shared library libAllpixModuleGenericPropagation.so
[ 94%] Built target AllpixModuleGenericPropagation
[ 96%] Linking CXX shared library libAllpixModuleGeometryBuilderGeant4.so
[ 96%] Built target AllpixModuleGeometryBuilderGeant4
make: *** [all] Error 2

should I do something different?

In gitlab by @mvicente on Jul 28, 2017, 17:20
closed

In gitlab by @Koensw on Jul 28, 2017, 18:10
The problem is resolved then I assume. How did you fix it?

In gitlab by @mvicente on Jul 28, 2017, 18:14
Partially.. I am still getting some errors during compilation sometimes.
I fixed the problem for now by rebasing my branch but when I first tried make install I got the error
CMake Error at tools/tcad_dfise_converter/cmake_install.cmake:42 (file):
  file INSTALL destination:
  /afs/cern.ch/user/m/mvicente/allpix-squared/bin/tcad_dfise_converter is not
  a directory.
Call Stack (most recent call first):
  tools/cmake_install.cmake:37 (include)
  cmake_install.cmake:43 (include)

make: *** [install] Error 1

so I did just make and what I need to continue working is working for now

In gitlab by @Koensw on Jul 28, 2017, 18:25
Aha okay then this issue was indeed related to some earlier changes I made.
Yes this is expected due to the way I moved stuff. Please delete your bin folder and run make install again should fix it.

In gitlab by @mvicente on Aug 4, 2017, 16:56
mentioned in issue #45

In gitlab by @mvicente on Jul 28, 2017, 18:29
it worked! thanks


Updated base solo

needs https://github.com/ipa320/cob_robots/pull/395

test on cob4-2: OK

CR: OK

Where is the stuff from base_collision_observer.launch now started?

this is only for the base_solo case which is a recovery mode if the complete robot bringup cannot be startet. Thus there's no need to launch the base_collision_observer here.
The base_collision_observer is still launched in the robot.xml files (complete bringup)

Right, makes sense! Fine for me then.

but why not keep it - at least commented out (as it is done for cob4's)?

Ok, accepted...merging


Form will not render Text Area

Issue Type
Bug Report
Description
This is related to the Form component.
Steps to Reproduce
Create a Form component with any item with editorType "dxTextArea".
Current Behavior
Creates error "E1035 - The editor cannot be created because of an internal error: $(...)[component] is not a function. See: http://js.devexpress.com/error/18_2/E1035"
Does not initialise a text area.
Expected Behavior
Should create a text area form element.
Demo
https://stackblitz.com/edit/devextreme-react-d9agth?file=index.js
Environment Details

"devextreme": "^18.2.3",
"devextreme-react": "^18.2.3",
"react": "^16.6.0",

After more reading, a seperate import is required for certain editor types. Closing.
https://js.devexpress.com/Documentation/Guide/Common/Modularity/Link_Modules/


优化在线性主题情况下 a-input-group 里面相邻组件间边框叠加导致粗的问题

[ ] I'm sure this does not appear in the issue list of the repository

Basic Info
What are the similar cases of this feature
无
What problem does this feature solve?
https://www.antdv.com/components/input-cn

@lin-97 hi, 是指现在官网的主题吗（官网现在看着是正常的）？还是其他主题才会出现？

长时间无回复，暂时关闭了。


[Feature Request] Disabling Console messages via config

Having an option to disable console messages via config would be great, as it gets rather spammy.
By console messages, I mean the messages saying Weather is <Weather> <Length in Seconds>.
(Sorry for the edits, my laptop was lagging and I accidentally submitted the issue before it was typed lmao)

v1.0.3 just released has this.

v1.0.3 just released has this.

Thanks :)

Thanks :)


[Beta@latest] Transition/Slide Internet Explorer

When using the Transition slide in I.E. the child component is not moved off of the screen. It seems like the css styles are not added at all for the default state.

[X] I have searched the issues of this repository and believe that this is not a duplicate.

Tech
Version

Material-UI
v1.0.0-beta.11

browser
IE 11

Chrome Element

IE 11 Element

The styles are added once in is true

I think the issue has to do with this
If you run this in IE it will never alert even though style.transform returns ""
(function() {
   if (document.querySelector('[direction="left"]').style.transform) {
     alert(true) }
    }
)()

I think its more likely something is wrong on the mount, but I do see that on line 121 https://github.com/callemall/material-ui/blob/v1-beta/src/transitions/Slide.js#L121 it is checking if transform exists

Actually it looks the issue is using calc within translate3d

From what i'm reading online if this is changed to use the translateX, Y functions we can combine them to get the same outcome as calc
https://stackoverflow.com/a/21469557
 if (direction === 'left') {
    return `translateX(100vw) translateX(-${rect.left}px)`;
  } else if (direction === 'right') {
    return `translateX(-${(rect.left + rect.width + GUTTER)}px)`;
  } else if (direction === 'up') {
    return `translateY(100vh) translateY(-${rect.top}px)`;
  }

@oliviertassinari is there an ETA on a fix being released for this?

@patrickml There is no ETA for any of the issues of the lib.
Generaly speaking, asking such question shows that's it important for people project and I can spend energy on other issues as people are more likely to handle the problem on their own.

Okay that makes sense. I think most of the issue can be fixed with the code I posted on https://github.com/callemall/material-ui/issues/8323#issuecomment-331337934

@patrickml The proposed solution sounds fair. Do you want to submit a PR? :)

Hi, I am using a Slide transition for a Popper (from react-popper). Using direction="right" works fine, but using direction="left" causes my container to appear in the screen instead of off-screen. Here is what it appears in the Chrome DevTools element.style:
transform: translateX(100vw) translateX(-956px)
The px property changes with viewport width. That is from @patrickml 's code, it seems. My problem is the container should not show up initially until the animation starts when the in property is set to true.
<Slide in={startAnimationFlag} direction="left">
  {/* ... */}
</Slide>

To fix my problem I have to remove the  translateX(-956px) part. I tested using Chrome 66  on macOS High Sierra.


Revert "feat(cheatcodes): Make expectCall only work for the next call's subcalls"

Reverts foundry-rs/foundry#4986
this was blocked for 1.0 and should not have been merged yet.

Could you please cut another release, @mattsse?
Our tests are failing now:
https://app.warp.dev/block/mLxbng37Ztgs9OxSko3PMf

already running, sorry for the inconvenience

TY @mattsse!
Also, FWIW, I don't think the implementation in #4986 works as expected.
Our tests already adhere to the rule of not counting calls made at the root test level, so it's strange that we started getting errors.
FWIW, the depth in our case is greater than usual, as we're routing the calls via delegatecall, specifically via the execute function in PRBProxy:
https://github.com/PaulRBerg/prb-proxy/blob/b5338c7e5a3a10468f584ea1f1caca08a510939a/src/PRBProxy.sol#L87
Lmk if you'd like access to the private repo @mattsse @Evalir for investigation. We also have a CI run that failed:
https://github.com/sablier-labs/v2-periphery/actions/runs/5071179085/jobs/9107504005

Hey @PaulRBerg, gotcha, this is great feedback. We're gonna start merging these into a feature branch, so we can run extended QA on big repos that use foundry heavily—we'll integrate prb-math and prb-proxy into external integration tests for this as well.
Would love access to the private repo—that way I can run QA and debug what might not be working as expected!

Can confirm that the latest release (3764b55 2023-05-24T17:24:24.100981000Z) works now, thanks guys.

Amazing, great to hear. Will probably be poking around really soon and testing with the new/upcoming changes!


Training is interrupted without error with MulitGPU

🐛 Bug

The training is interrupted randomly in the middle of an epoch without errors. The console only says: Terminated.
The error does not necessarily occur, if it does then mostly between epochs 2-4. It is noticeable that processes are still running after the termination, the graphic cards are still used by python processes.
We train the PyTorch version of the ImageGPT model with huggingface transformers. Could also be problem of huggingface, we are not sure.
Epoch 1:  29%|█▍   | 9413/32393 [3:28:18<8:28:33,  1.33s/it, loss=3.23, v_num=9]Terminated
Please reproduce using the BoringModel
Cant reproduce with Boring Model.
Code

class ImageGPT(pl.LightningModule):

    def __init__(self,
                 learning_rate=learning_rate
                 ):
        super().__init__()
        self.gpt2 =  ImageGPT2LMHeadModel(config=...)
        self.criterion = nn.CrossEntropyLoss(reduction='none')
        self.learning_rate = learning_rate

    def forward(self, x):
        return self.gpt2(x, past_key_values=None)

....

logger = pl_loggers.TensorBoardLogger(save_dir="logs", name=name)

checkpoint_callback = ModelCheckpoint(
        save_top_k=1,
        verbose=True,
        monitor='val_loss',
        mode='min',
        filepath='../models',
        prefix='ImageGPT'
    )

trainer = Trainer(
                accelerator='ddp',
                max_epochs=10,
                max_steps=None,
                precision=32,
                accumulate_grad_batches=1,
                gpus=[0, 1, 2],
                callbacks=[checkpoint_callback],
                logger=logger,
                gradient_clip_val=0.6
            )

trainer.fit(model=model, datamodule=datamodule)

Expected behavior
The training is fully completed across all epochs.
Environment

CUDA:

GPU:

TITAN RTX
TITAN RTX
TITAN RTX

available:         True
version:           10.2

Packages:

numpy:             1.19.4
pyTorch_debug:     False
pyTorch_version:   1.7.1
pytorch-lightning: 1.1.2
transformers:          3.5.1
tqdm:              4.55.0

System:

OS:                Linux, 64bit
processor:         x86_64
python:            3.7.4
version:           86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020

Additional context

We have made the following points to solve the problem:

set the num-workers of the dataloaders to 0 or 1 (instead of 32-64)
go back to 32 bit precision
different learning rates
added gradient clipping
used AdamW implementation from huggingface

This happens to me too, but I don't get "Terminated" at end of progress bar, it just stops, and when I check the system with "top i", I see 4 python processes running at 100% and 4 GPUs at about 90% capacity but nothing is changing. Sometimes, after like an hour or two, it just randomly restarts but the s/it jumps from 2.5 to like 85.

@angadkalra +1. For me switching to DP solves the problem, but it at the cost of speed.

Hi everybody! If any of you can provide a snippet that would be awesome. Otherwise we are blind trying to fix it.

Hi everybody! If any of you can provide a snippet that would be awesome. Otherwise we are blind trying to fix it.

Code snippet? Is the code in the original post good enough or need colab?

Need something I can run. Preferably a colab 👍

@carmocca Sorry for the late reproducible example! Please see below for a self-contained example that uses two GPUs for DDP. For me the code gets stuck at epoch 13, while the two GPUs keep busy at 100%. Switching to DP solves the problem.

My settings:
pytorch: 1.7.1 + CUDA 11.0
pytorch-lightning == 1.1.8
GPUs: 2080 Ti x2
import torch
import pytorch_lightning as pl
import torch.nn.functional as F
import torch.optim as optim

from torch import nn
from torch.utils.data import Dataset, DataLoader

# set random seed
torch.backends.cudnn.deterministic = False
torch.backends.cudnn.benchmark = True
torch.backends.cudnn.enabled = True

# Define Dataset
class CCDataset(Dataset):

    def __init__(self, data):
        self.data = data

    def __len__(self):
        return self.data.shape[0]

    def __getitem__(self, idx):
        target = self.data[idx,0].clone().detach()
        features = self.data[idx,1:].clone().detach()

        return target, features

# then define DataModule
class CCDataModule(pl.LightningDataModule):
    def __init__(self):
        super().__init__()

    # Dataset
    def setup(self):
        # read the train and test dataset
        # targets_train = feather.read_feather('targets_train.feather')
        # targets_val = feather.read_feather('targets_test.feather')
        targets_train = torch.rand(12157,16)
        targets_val = torch.rand(12157,16)

        self.train_dataset = CCDataset(targets_train)
        self.val_dataset = CCDataset(targets_val)

    # DataLoader
    def train_dataloader(self):
        return DataLoader(self.train_dataset, batch_size=64,
                          shuffle=True, drop_last=False, num_workers=2,
                          pin_memory=True)

    def val_dataloader(self):
        return DataLoader(self.val_dataset, batch_size=64,
                          num_workers=2, pin_memory=True,
                          drop_last=False)

# # def Model

class Model(pl.LightningModule):
    '''Mainly define the `*_step_end` methods
    '''
    def __init__(self):
        super().__init__()

        # dropout layers
        self.dropout_1 = nn.Dropout(0.5)

        # fc layers
        self.fc_1 = nn.Linear(15, 16)
        self.fc_2 = nn.Linear(16, 1)

    def shared_step(self, batch):
        t, x = batch
        x = self.dropout_1(F.relu(self.fc_1(x)))
        y = self.fc_2(x) # (N, 1)

        return y.squeeze(), t

    # train step
    def training_step(self, batch, idx):
        y, t = self.shared_step(batch)
        return {'y': y, 't': t}

    # validation step
    def validation_step(self, batch, idx):
        y, t = self.shared_step(batch)
        return {'y': y, 't': t}

    # loss
    def mse_loss(self, y, t):
        return F.mse_loss(y, t)

    # def training_step_end
    def training_step_end(self, outputs):
        y = outputs['y']
        t = outputs['t']
        loss = self.mse_loss(y, t)

        return {'loss':loss}

    # def validation_step_end
    def validation_step_end(self, outputs):
        y = outputs['y']
        t = outputs['t']

        return {'y': y, 't': t}

    # validation step
    def validation_epoch_end(self, outputs):
        y = torch.cat([x['y'] for x in outputs])
        t = torch.cat([x['t'] for x in outputs])

        loss = self.mse_loss(y, t)
        rmse = torch.sqrt(loss)
        self.log('val_rmse', rmse, on_step=False)

    # optimizer
    def configure_optimizers(self):
        optimizer = optim.Adam(self.parameters(), lr=1e-4)
        return optimizer

# # Run

# checkpoint
checkpoint_callback = pl.callbacks.ModelCheckpoint(
    verbose=True,
    mode='min',
    monitor='val_rmse',
    save_top_k=1)

# trainer
trainer = pl.Trainer(gpus=[0,1],
                     checkpoint_callback=checkpoint_callback,
                     accelerator='ddp',
                     min_epochs=10,
                     max_epochs=500)

# loop over windows
torch.manual_seed(42)

# init model
model = Model()

# create datamodule
datamodule = CCDataModule()
datamodule.setup()

# train the model
trainer.fit(model, datamodule)

I observe the same behaviour as @angadkalra:

This happens to me too, but I don't get "Terminated" at end of progress bar, it just stops, and when I check the system with "top i", I see 4 python processes running at 100% and 4 GPUs at about 90% capacity but nothing is changing. Sometimes, after like an hour or two, it just randomly restarts but the s/it jumps from 2.5 to like 85.

This is pretty severe issue, basically making the training impossible for non-toy models - in my case, removing ModelCheckpoint callback makes the training proceed, but what's the point?

I observe the same behaviour as @angadkalra:

This happens to me too, but I don't get "Terminated" at end of progress bar, it just stops, and when I check the system with "top i", I see 4 python processes running at 100% and 4 GPUs at about 90% capacity but nothing is changing. Sometimes, after like an hour or two, it just randomly restarts but the s/it jumps from 2.5 to like 85.

This is pretty severe issue, basically making the training impossible for non-toy models - in my case, removing ModelCheckpoint callback makes the training proceed, but what's the point?

For me, I turn my VM off and on and it'll train fine for many epochs...

Regarding the reproducible code above, I think I can confirm that this is due to the validation_epoch_end returning different loss's on each process, leading to the model checkpoint logic being in de-sync with multiple processes (something that the lightning metrics package handles: https://pytorch-lightning.readthedocs.io/en/latest/extensions/metrics.html)
I know this is incorrect metrically, but as a test I'd suggest changing self.log('val_rmse', rmse, on_step=False) to self.log('val_rmse', rmse, on_step=False, sync_dist=True) and seeing if this works.
If this does, two longer term solutions would be to define your own pl.Metric (I can assist here, should be easy) which will handle distributed synching for you and gathering all the outputs, or trying to use the self.gather function within the validation_epoch_end function, which will be trickier.

I know this is incorrect metrically, but as a test I'd suggest changing self.log('val_rmse', rmse, on_step=False) to self.log('val_rmse', rmse, on_step=False, sync_dist=True) and seeing if this works.

Hi @SeanNaren, I can confirm by adding sync_dist=True the problem is gone. Would you please help me set up a custom pl.Metric? Thank you!

I'm only calling self.log in the *_step without any custom metrics (just with loss) and adding sync_dist=True does not resolve the issue.

I know this is incorrect metrically, but as a test I'd suggest changing self.log('val_rmse', rmse, on_step=False) to self.log('val_rmse', rmse, on_step=False, sync_dist=True) and seeing if this works.

Hi @SeanNaren, I can confirm by adding sync_dist=True the problem is gone. Would you please help me set up a custom pl.Metric? Thank you!

Sure, I'll try get some time, in the meantime I tested the all_gather function which works fine. Just change your validation_epoch_end to look like this:
        # validation step
    def validation_epoch_end(self, outputs):
        y = torch.cat([x['y'] for x in outputs])
        t = torch.cat([x['t'] for x in outputs])
        y = self.all_gather(y)
        t = self.all_gather(t)

        loss = self.mse_loss(y, t)
        rmse = torch.sqrt(loss)
        self.log('val_rmse', rmse, on_step=False)

Let me give some context as to why this fix works. When we run validation across distributed processes, each GPU/process gets a different set of data batches. This means the score calculated on every GPU is different, unless we do some form of synchronisation between the process. This can either be done via:

Use the pl.Metric library which has a few helpful functions to synchronize the metric across processes, so even though each GPU has different batches of data, we sync our metric result across process (efficient and clean). If you do this, you won't need to override the epoch end hook.
If you override validation_epoch_end this doesn't automatically sync the batches across processes. This is because in many cases you don't want to do this, i.e if you're using a pl.Metric to handle this instead. If you do want to sync, you can sync tensors and some python primitives using self.all_gather like suggested above!

@marrrcin maybe the explanation could be insightful? If you're running into a different error and can get a reproducible script let me know, I can help resolve

Need something I can run. Preferably a colab 👍

Sorry for the long wait, but here is a Google Colab for the code from the output post [https://colab.research.google.com/drive/1FhhrQLJonLWNeLF3QCwopqkf2Y_jGrA2?usp=sharing]

I observe the same behaviour as @angadkalra:

This happens to me too, but I don't get "Terminated" at end of progress bar, it just stops, and when I check the system with "top i", I see 4 python processes running at 100% and 4 GPUs at about 90% capacity but nothing is changing. Sometimes, after like an hour or two, it just randomly restarts but the s/it jumps from 2.5 to like 85.

This is pretty severe issue, basically making the training impossible for non-toy models - in my case, removing ModelCheckpoint callback makes the training proceed, but what's the point?

Good to know, i will try it without ModelCheckpoint, also with sync_dist=True

For me, I turn my VM off and on and it'll train fine for many epochs...
No VMs installed on training system

Need something I can run. Preferably a colab 👍

Sorry for the long wait, but here is a Google Colab for the code from the original post PyTorchImageGPT

I observe the same behaviour as @angadkalra:

This happens to me too, but I don't get "Terminated" at end of progress bar, it just stops, and when I check the system with "top i", I see 4 python processes running at 100% and 4 GPUs at about 90% capacity but nothing is changing. Sometimes, after like an hour or two, it just randomly restarts but the s/it jumps from 2.5 to like 85.

This is pretty severe issue, basically making the training impossible for non-toy models - in my case, removing ModelCheckpoint callback makes the training proceed, but what's the point?

Good to know, i will try it without ModelCheckpoint, also with sync_dist=True

For me, I turn my VM off and on and it'll train fine for many epochs...

No VMs installed on training system

I see iGPT, which may require find_unused_parameters=True set to True. In Pytorch Lightning this is set to False by default, could you try something like below when training?
from pytorch_lightning.plugins import DDPPlugin

trainer = pl.Trainer(
    gpus=2,
    checkpoint_callback=checkpoint_callback,
    accelerator='ddp',
    plugins=DDPPlugin(find_unused_parameters=True),
)

Have you guys tried updating to v1.2? I'm using Metrics API now instead of returning batch dict and everything is working fine, using ModelCheckpoint callback too. I haven't got any freezing so far.

@skull3r7 @marrrcin @XiaomoWu please let us know if that resolves the issue!

@edenlightning @SeanNaren sorry for the late reply. Yes the problem is solved, either by using the pl.Metric or overriding validation_epoch_end with all_gether. Thank you so much for the help!

DDPPlugin(find_unused_parameters=True) seems to fix the problem for me too.

Thanks @marrrcin for coming back to us! We've got a discussion here to turn this flag back on, or expose it to the trainer: https://github.com/PyTorchLightning/pytorch-lightning/discussions/6219
If anyone has thoughts please leave them there, it seems that at this point we should turn find_unused_parameters=True as default, and write in the docs that if you would like to see a speed up using traditional DDP, to turn this flag off.

Actually keeping this open, to track setting the default to true or any other solution you come up with.

I suggest:

put a reminder in the section of Logging of the doc that logging with distributed training need special handling and care, and then refer to the section Multi-GPU training/Prepare your code/Synchronize validation and test logging
add more examples of properly overriding hooks like validation_epoch_end in the section Multi-GPU training/Prepare your code/Synchronize validation and test logging

I have the same issue, but only running on one GPU.

I know this is incorrect metrically, but as a test I'd suggest changing self.log('val_rmse', rmse, on_step=False) to self.log('val_rmse', rmse, on_step=False, sync_dist=True) and seeing if this works.

This suggestion didn't work for me, but setting rank_zero_only=True did the trick.

In my case, the training stops after epoch 0 (right before the end of validation end). Setting drop_last  in Dataloader solves the problem!


Getting typescript errors during npm build on azure-rest/core-client used by azure purview data catalog SDK

I'm trying to use azure-rest/purview-catalog Javascript SDK (https://www.npmjs.com/package/@azure-rest/purview-catalog), after importing/installing in into my project, I'm getting below errors when I'm running the build using command npm run build.
⠇  Building for production...node_modules/@azure-rest/purview-catalog/node_modules/@azure-rest/core-client/types/latest/core-client-rest.d.ts:165:76 - error TS1110: Type expected.

165 export declare type PathParameters<TRoute extends string> = TRoute extends `${infer _Head}/{${infer _Param}}${infer Tail}` ? [
                                                                               ~~~

node_modules/@azure-rest/purview-catalog/node_modules/@azure-rest/core-client/types/latest/core-client-rest.d.ts:165:85 - error TS1005: '}' expected.

165 export declare type PathParameters<TRoute extends string> = TRoute extends `${infer _Head}/{${infer _Param}}${infer Tail}` ? [
                                                                                ~~~~~

node_modules/@azure-rest/purview-catalog/node_modules/@azure-rest/core-client/types/latest/core-client-rest.d.ts:165:90 - error TS1128: Declaration or statement expected.

165 export declare type PathParameters<TRoute extends string> = TRoute extends `${infer _Head}/{${infer _Param}}${infer Tail}` ? [
                                                                                ~

node_modules/@azure-rest/purview-catalog/node_modules/@azure-rest/core-client/types/latest/core-client-rest.d.ts:165:92 - error TS1161: Unterminated regular expression literal.

165 export declare type PathParameters<TRoute extends string> = TRoute extends `${infer _Head}/{${infer _Param}}${infer Tail}` ? [

node_modules/@azure-rest/purview-catalog/node_modules/@azure-rest/core-client/types/latest/core-client-rest.d.ts:167:1 - error TS1109: Expression expected.

167 ...pathParameters: PathParameters<Tail>
    ~~~

node_modules/@azure-rest/purview-catalog/node_modules/@azure-rest/core-client/types/latest/core-client-rest.d.ts:168:1 - error TS1005: '(' expected.

168 ] : [
    ~

node_modules/@azure-rest/purview-catalog/node_modules/@azure-rest/core-client/types/latest/core-client-rest.d.ts:168:3 - error TS1135: Argument expression expected.

168 ] : [
      ~

node_modules/@azure-rest/purview-catalog/node_modules/@azure-rest/core-client/types/latest/core-client-rest.d.ts:169:2 - error TS1005: ')' expected.

169 ];
     ~

Found 8 errors.

azure-rest/purview-catalog uses azure-rest/core-client and this code below in this library is resulting in these errors:
export declare type PathParameters<TRoute extends string> = TRoute extends `${infer _Head}/{${infer _Param}}${infer Tail}` ? [
pathParameter: string,
...pathParameters: PathParameters<Tail>
] : [
];

I tried installing the previous version of this SDK as well, but was getting similar errors on RouteParams.
Package link :
https://www.npmjs.com/package/@azure-rest/purview-catalog
Version details:
Node.js : 14.0.0
typescript version : 4.6.3
@azure-rest/purview-catalog : 1.0.0-beta.4
@azure-rest/core-client: "1.0.0-beta.9" (installed as a dependency of @azure-rest/purview-catalog)
I need to know is it any specific typescript version or library I need to install to make this work? how can I can around this error and do a successful build?
Really looking forward to hear back on this soon, thanks

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Azure.Core:0.23571861,Storage:0.11249013,Azure.Identity:0.06860241'

Hi @shahtajk7, this looks like an issue from an older version of TypeScript not supporting string literals. I see that you are using TypeScript version 4.6.3 which should support this feature. Is there any chance that an older version of TypeScript is installed globally in your system and is being used instead of the TS version you installed in your project?
A quick way to check the global TS version is:
tsc --version

And within your package you can run the following to double-check the version installed
npx tsc --version

If the global TS version seems old, you can try 2 things to make sure the actual TS dependency you added in your package is used. The first option is to create a build script in your package.json  something like this:
{
   "scripts": {
         "build": "tsc"
      }
}

And build using npm run build.
The second option is to build using npx tsc instead of just tsc npx will use the version of the dependency found in your package.json. Also the package.json script will use the tsc version in its dependency list.
Let me know if this solves your problem

@joheredi Thanks, yes the project was using the old version, fixing it fixed the errors, thanks.

Glad to hear that the issue is solved. Please keep the feedback coming in 😄


Getting Out of memory error while reading RMap, Map contains over 200k data

Code  :
RMap.readAllValues().stream().forEach => OOM Getting here..
Can someone please help me out, Is any available solution to read this load data in RMap, or will have to be read in batches ??

Do I need to get the complete size if RMap and run through loop to get data in batches or Redission will take care itself?

Redisson will take care itself.

Thanks for the quick reply, Once more help I need since my RMap data size will vary from 10K to 250K, What would be the ideal batch size :
RMap<String, Object>.values(CACHE_BATCH_READ_SIZE).forEach
CACHE_BATCH_READ_SIZE ??

that depends on data size


Migrate crowdin from main repo

https://crowdin.com/project/verdaccio/settings#integration

Issue blocking us
https://github.com/facebook/Docusaurus/issues/1112
fixed here https://github.com/facebook/Docusaurus/pull/1119
waiting next release.


Fix lastmod times in site index

Reviewer checklist

[ ] Read the contributing guide
[ ] PR should be motivated, i.e. what does it fix, why, and if relevant, how
[ ] Ensure relevant issues are linked (description should include text like "Fixes #")
[ ] Ensure any appropriate documentation has been added or amended

Coverage: 93.284%. Remained the same when pulling 19aae26cc2607398a615fe70aef6b9be70ea5cf8 on sitemap_times into 308ffe9e9bde2aebabf703fa18a837e77a68e414 on main.


Add subscription channel field

We recently noticed that when a default value is not provided, the system incorrectly defaults to dev-preview. Details are provided in CNV-51160.
This PR addresses the problem by making it configurable, allowing the appropriate value to be selected.

@newkit Hello, could you please review. Thanks


Custom timeoutInterval doesn't work

I'm trying to increase the default timeoutInterval of 1 minute to 10 minutes with this code:
var request = URLRequest(url: URL(string: "ws://localhost:80/ws")!)
request.timeoutInterval = 600
let ws = WebSocket(request: request)

Still this doesn't work. Any idea what I might be doing wrong? After 1 minute, the onDisconnect handler is called with error = nil.

That is the right setup, but the disconnect code isn't "builtin" to the API that is using it (old foundation API). I refactored that logic in 4.0.0 to help with disconnect time and started using the Network framework which does support timeouts. Upgrading should resolve the issue unless it is related to something other than the timeout in the socket API.

Thanks, it works now.

Sorry, I thought it worked but it still doesn't. Even when setting request.timeoutInterval = 5 the timeout happens at 60 seconds. Have you tried it?


fix: fast refresh stops on needed bail outs

Fast Refresh requires the HMR runtime to support bail out behaviour (we do not do so within the core runtime as it has to be platform agnostic) - and currently webpackHotDevClient does not do so properly as it circumvents the logic for forced reloads completely when using Fast Refresh.
The changes done here ensures that:

If Fast Refresh is not enabled, we would always bail out to a forced reload;
If Fast Refresh is enabled and there are updated modules, it indicates the update has at least partially executed, and we can rely on Fast Refresh being resilient to errors and skip the forced reload;
If Fast Refresh is enabled and there are none updated modules, check for the status of the hot update. If it is abort or failed, it indicates the update cannot be executed without being inconsistent (i.e. Fast Refresh bailed out), we would bail out to a forced reload.

To verify the impact of this change:

Start a new project with CRA v4, update App.js with multiple exports (e.g. pmmmwh/react-refresh-webpack-plugin#426)
Run the project, try updating App.js with anything. Without this PR changes would not propagate on screen.
With this PR, the page should force refresh and propagate the changes.

To verify addendum to this change (error recovery):

Using the same project, remove extra exports in App.js
Run the project, wait for the first compilation to complete
Try adding a throw new Error('no') within the App component, compilation should show the error overlay
Try removing the error within the component, App should HMR properly without forced refresh
Try creating syntax errors within the module (e.g. remove quotation marks in imports), compilation should show the error overlay
Try fixing the error, App should HMR properly without forced refresh

This should:
Fixes #9904
Fixes #9913
Fixes #9984
Fixes Partially #10078
Fixes #10287
Fixes #10539
Fixes #10606
Fixes #11087

Updated heuristic to cover more cases (to be on the safe side) where we would force a reload, especially when Webpack signifies that the HMR update is aborted or failed completely (indicating applying the update would yield inconsistency).

Thanks! Looking forward to getting these enhancements out in v5!


Add .editorconfig

Codecov Report

Merging #66 (bb3c74c) into master (a208d3e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #66   +/-   ##
=======================================
  Coverage   81.14%   81.14%
=======================================
  Files          11       11
  Lines         488      488
=======================================
  Hits          396      396
  Misses         88       88
  Partials        4        4

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 a208d3e...bb3c74c. Read the comment docs.


Cluster menu error: TypeError: instance of IpcRenderer is not created

When clicked cluster sidebar menu, the error appeared in console:
Uncaught (in promise) TypeError: instance of IpcRenderer is not created

https://user-images.githubusercontent.com/9607060/155716926-64e21ff3-b265-43a3-8ff1-672b3954a007.mov
However, all menu items work okay - Remove from hotbar, Delete, Disconnect etc.

This is an extension issue, closing to move.


1Password Support

https://www.raywenderlich.com/92667/securing-ios-data-keychain-touch-id-1password


⚠ Secret Website 3 has degraded performance

In 9ffaa71, Secret Website 3 ($SECRET_WEBSITE_3) experienced degraded performance:

HTTP code: 200
Response time: 2428 ms

Resolved: Secret Website 3 performance has improved in 1ca95a9.


Improve API data validation in serializers

During create or update process of serializers, sometimes KeyError occurs and currently, we aren't handling them. We can implement validations to check if required fields are present and if there is a problem, we can raise serializers.ValidationError and this returns a message we specify plus meaningful status code.

@kirbiyik That makes your tasks easier and yes, we can do this. :)

I think we can add required attribute so it raises an error during validation.

I am making some of the fields optional according to principles that we have been talking in #99

I think we should go all or none. Otherwise recommendation and search might be troublesome due to gaps in data.

This step is done. There are no KeyErrors anymore. We will be continuing different aspects of validation problems on issue #118


WIP: Test newer version of nuget-project-pack

Description

References

#0000

Test succeeded, closing PR