error about epoch print statement when i use the main.py to train with ucf101 dataset

Hi, @yjxiong
I use the main.py script to train ucf101 , but the script encount an error when it ends an epoch. the error as below:
Traceback (most recent call last):
File "main.py", line 307, in
main()
File "main.py", line 130, in main
train(train_loader, model, criterion, optimizer, epoch)
File "main.py", line 206, in train
data_time=data_time, loss=losses, top1=top1, top5=top5, lr=optimizer.param_groups[-1]['lr'])))
TypeError: unsupported format string passed to torch.cuda.FloatTensor.format
After I check the script, it is the print statement makes the programme terminated.
print(('Epoch: [{0}][{1}/{2}], lr: {lr:.5f}\t'                   'Time {batch_time.val:.3f} ({batch_time.avg:.3f})\t'                   'Data {data_time.val:.3f} ({data_time.avg:.3f})\t'                   'Loss {loss.val:.4f} ({loss.avg:.4f})\t'                   'Prec@1 {top1.val:.3f} ({top1.avg:.3f})\t'                   'Prec@5 {top5.val:.3f} ({top5.avg:.3f})'.format(                    epoch, i, len(train_loader), batch_time=batch_time,                    data_time=data_time, loss=losses, top1=top1, top5=top5, lr=optimizer.param_groups[-1]['lr'])))
Thanks in advance~

figure out ,close


⚠ Bofrost.fr has degraded performance

In da17ad8, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1026 ms

Resolved: Bofrost.fr performance has improved in df4af1c.


Move Cassandra pilot creation to ScaleOut

I think it make sense to create pilots during scaleout rather than as a separate control.
And then in #285 we can remove the pilot during scale down.

/kind feature

We're trying a generic pilot controller instead: https://github.com/jetstack/navigator/pull/353


Filters on schema for Snowflake are not applied for Relationships extraction

At this point filters feature even was not added to the Snowflake.


Added a new file "thalicryptomanager.js" which has an API to obtain the

public-key-hash value. Also added new functionality to the "ThaliReplicationManager.prototype.start" function where the public-key-hash is obtained for the device and it is added to the DB if needed.

[ ]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-62
 This is going to break when you merge with story 0 because we no longer include thali via file path, instead its now a normal NPM dependency. So this path should become 'thali/thalicryptomanager'
 Will fix this when I merge with story-0.
[ ]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-131
 So... um.... just out of curiosity... (don't you dare fix this!) But why would you use fs.mkdirSync on line 18 and then use fs.remove instead of fs.removeSync on line 22? Again, DON'T FIX THIS! But doesn't this just feel wrong to you?  You now make the developer wonder - why did he use a sync fs function and then 4 lines later use an async one? In this case blocking on sync is find since the tests are going to block anyway (they are linear) and you could completely skip the if(err) step since the sync version will throw an exception.
to be clear, your code is correct. It will work. This isn't worth fixing. My only point in sending this message is to try and show examples where your developer instincts should 'ping' and bug you.
[ ]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-122
 DON'T FIX THIS! But for future reference it would have been cleaner to have said t.ok(publicKey && publicKey.length >0, "extracted public key is invalid");
[ ]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-122
 DON'T FIX THIS! But for future reference it would have been cleaner to have wrapped this whole thing in t.doesNotThrow(...., "crypto.pkcs12 failed") rather than use a try/catch.
[x]   File: thali/thalicryptomanager.js:L1-95
 We should follow the usual node.js convention of returning an error in the first argument and success information in the second argument. So we should be returning an error string in the first argument here not null.
 Correct, it must be in the form of cb(err, ...args) where the error is always first even if null/undefined, meaning cb() is perfectly valid if there are no errors and no return value.
 Fixed as per comments.
[x]   File: thali/thalicryptomanager.js:L1-95
 Typically just concatenating paths isn't safe across OS's. I think Node.js has a function somewhere in FS to handle safe file concatenation. Can you please find it and use it?
 Yes, use path.join https://nodejs.org/api/path.html#path_path_join_path1_path2
 Fixed as per comments.
[x]   File: thali/thalicryptomanager.js:L1-95
 Same callback comment as above and again in line 42 and so on.
 Fixed.
[x]   File: thali/thalicryptomanager.js:L1-95
 I would restructure this code so there is one function that checks if the file exists and if not creates it and if so returns it. So in either case the function will return the file contents. Then I would have code that takes the returned value and gets the public key and generates the hash. that way we wouldn't have identical code in two places like we have in 39-46 and 65-72 and I think the code would be easier to read.
 Fixed as suggested.
[x]   File: thali/thalicryptomanager.js:L1-95
 Why did you go through all the trouble to create a Buffer when you end up only using the value as a string? In fact, when would it ever be used as a buffer?
 Fixed by returning a string.
[x]   File: thali/thalicryptomanager.js:L1-103
 Please put in a comment specifying that we use a bogus password because using a password at all is bogus. Anyone who can get to the file can get to the app and thus can get the password. So we just include something because the API expects it. If and when mobile devices start having secure key stores that are tagged to app IDs then we can discuss using a real password.
 I'll go file an issue that we really should be using the key stores on both iOS and Android. But keep in mind that this only provides a nominal security benefit since no secure hardware is being used. Instead what it does it store the keys in an encrypted file based off the device's key. This does provide some (tiny) level of protection for unencrypted devices. For devices that encrypt their drives it provides no meaningful protection. As such I think adding in support for local keystores is low priority.
 Added the comment.
 I don't see a comment.
 The comment was added in a different place. Now moved it here.
[x]   File: thali/thalicryptomanager.js:L1-103
 This description is not correct. It would be better to use a correct description which is that this function looks for a pkcs12 file in a known location and will create it if it doesn't exist and then extract the public key and return its SHA256 hash.
 Gave a correct/complete description.
[x]   File: thali/thalicryptomanager.js:L1-103
 Is this really necessary in the log? Please review your console.log statements and ask yourself "Will anyone benefit by adding all of this to the log?" The more stuff is in the log the harder it is to use for much of anything. We already have a work item to add some kind of log leveling but we aren't there yet.
 Removed all the unnecessary log statements.
[x]   File: thali/thalicryptomanager.js:L1-103
 Why doesn't the JSDoc specify the callback? See http://usejsdoc.org/tags-callback.html
 Added the callback description  here and other functions as necessary.
[x]   File: thali/thalireplicationmanager.js:L39-109
 Where is the jsdoc for deviceName?
 The deviceName parameter is not being passed to the thalireplicationmanager's start function anymore. The device-name/device-identity is already available in the thalireplicationmanager.
[x]   File: thali/thalireplicationmanager.js:L6-13
 Why is addressPrefix in the thalireplicationmanager? That is something that is specific to the postcardapp. It is not generic to Thali at all. It shouldn't be Thali_CordovaPlugin, it should be in postcardapp.
 Fixed as part of the redesign where the thalireplicationmanager does not add anything o the DB.
[x]   File: thali/thalireplicationmanager.js:L39-109
 This should not be here per my previous comment. I think it makes sense for the cryptomanager to be here. I think it makes sense for the cryptomanager to be part of start up (after all, you can't do replication with an identity). I even think it makes sense for the cryptomanager to get the publickeyhash. But that is where it ends. That publickeyhash should be available as a property identifying the current device but that's it. It should be up to the postcardapp to then get that publickeyhash and use it for something.
Please propose a design for how we can expose the publickeyhash all the way to the postcardapp in a manner that makes logical sense.
 Completed the redesign as proposed.
[x]   File: thali/thalireplicationmanager.js:L39-109
 Again, this is postcardapp specific. It's not generic to Thali. I do believe that eventually Thali should have a central address book store and when we work on ACLs and identity exchange we will add one. But for now the thali replication manager can only handle one DB at a time so we agreed to put the addressbook entries in it but that should be an app level (e.g. postcardapp) consideration, not a Thali_CordovaPlugin consideration.
 Fixed as part of the redesign.
[x]   File: thali/thalireplicationmanager.js:L39-109
 There should be 2, not 3 ds in Addr. Actually it's generally not recommended to use abbreviations. Now that we have auto-complete in our IDEs it's better to just use the full word, e.g. currentAddressFound.
 I am not using abbreviations anymore.
[x]   File: thali/thalireplicationmanager.js:L39-109
 Please don't check into story main with a todo like this. Please add in the error handler!
 This entire DB operation has been moved to the app. I also handled the DB operation error there.
[x]   File: thali/thalicryptomanager.js:L1-105
 /piblic/public
 fixed.
[x]   File: thali/thalicryptomanager.js:L1-105
 In general you don't need to document internal functions and you especially don't need to document such a short function. Typically headers like this are only needed on public functions or on functions that do something really confusing and so could benefit from extra explanation. Remember, comments rot. So we only want to use them when the value they bring is greater than the cost of maintaining them.
 Removed the documentation.
[x]   File: thali/thalireplicationmanager.js:L7-15
 Why introduce currentDeviceIdentity if we already have _deviceName?
 Fixed.
[x]   File: thali/thalireplicationmanager.js:L67-75
 Please remove the comment on line 70 and 71. This is just the kind of comment that rots really quickly as soon as there is an edit. We have IDEs to handle matching squiggly braces.
 Fixed.
[x]   File: thali/thalireplicationmanager.js:L113-141
 Why are you requiring this down here rather than at the top of the file?
 Moved the getDeviceIdentity function to the top of the file.
 I wasn't referring to the function definition. I was referring to your use of require('./thalicryptomanager'). Generally it is considered good practice to put require statements at the top of the file. See http://justbuildsomething.com/node-js-best-practices/#2 for an example why.
 I declared the "require" here as it  is used only one time here. But you are right, it is better to put it at the top. I moved it now.
[x]   File: thali/thalireplicationmanager.js:L113-141
 Please remove this comment. When the function is called 'getPublicKeyHash' it's pretty clear what's going on.
 Done.
[x]   File: thali/thalicryptomanager.js:L1-111
 I believe this code suffers from a very nasty race condition! Imagine that two people call getPKCS12Content at the same time (this can easily happen if two calls to getDeviceIdentity are made) and the PKCS12 file doesn't exist yet. In that case both calls can get false on line 70 (since exists is an async function) and both calls can successfully get to line 92 and both will succeed on line 92 (since writeFile is async and explicitly overwrites if the file already exists) and so there will be two callbacks with two difference public keys for the same device!
Thankfully I think there is a pretty easy fix. If you pass in the "wx" flag to writeFile then it should fail if the file already exists. In that case exactly one of the two calls would succeed on the write, the other would get a file exists error.
 The fix will not work entirely... The 2nd call to writeFile will fail as you explained. But the 2nd guy who called getPKCS12Content will not get the content and thus will not get the public key hash.
This is better than having two different public keys for the same device but the 2nd guy will have to retry by calling getPublicKeyHash again.
 Please ignore my above comment. You already mentioned the issue below.
 Fixed as suggested.
[x]   File: thali/thalireplicationmanager.js:L113-141
 Assuming you make the change I talked about in the the crypto file to deal with the race condition we still have a problem with this code. Which is that if the function gets called twice when there is no existing PKCS12 file then one of the two calls can end up with an error because the underlying write failed. That sort of thing shouldn't be visible (or be a concern) for someone calling getDeviceIdentity.
The problem is that fixing this is tricky because it's possible that when the error is returned the PKCS12 file may have been created but currentDeviceIdentity hasn't been set yet.
There are several traditional ways to deal with this in Node.js land -
Promises - We could use promises to work around this by creating a promise to retrieve the public key from the file and then adding any cbs to a then on that promise. They will then automatically be run once the ID is returned. But I don't think it's worth adding the promises library (we are using lie) just to solve this one issue.
Flags - Another traditional approach is some kind of state flag. You set the flag initially to 'noDeviceIdentitySet' and then when the first call is made to getDeviceIdentity this will cause you to set the flag to 'gettingDeviceKey' and you will then make the call to getPublicKeyHash. Any calls to getDeviceIdentity while the flag is set to 'gettingDeviceKey' will just have their cb added to a cb array. When getPublicKeyHash returns then you would set the flag to 'deviceKeyAvailable' and you would call all the cbs in the arrays. Any future calls to getDeviceIdentity would just immediately return the value since the state is 'deviceKeyAvailable'.
Event Emitter - The third approach is to use an event emitter. This is a bit more complicated but basically you could attach the CBs as a listener to the event emitter and once the key is available then you would emit the event which would trigger the CBs. You would also need to check if the device identity is already available and skip the emitter all together in that case. Honestly I think this is more work than it's worth.
So my suggestion would be the flag approach.
@mattpodwysocki - What do you think is the best way to handle this race condition? Or is there no race condition and I'm just hallucinating?
 Fixed using flags.
[x]   File: thali/thalireplicationmanager.js:L47-101
 I apologize if I'm missing something but I don't see a check anywhere here that this._deviceName is actually set. There seems to be an assumption that getDeviceIdentity will always be called before start. That seems like a dangerous assumption to make. If in fact we are making that assumption then I would suggest that code should be 'fail safe'. That is, either start should fail if getDeviceIdentity hasn't been called or we should build getDeviceIdentity into start just to make sure. The later seems preferable.
Sorry if I missed where deviceName was guaranteed to be set.
 Fixed by building getDeviceIdentity if user has not done it before calling start. This involved moving around the code as well as adding new functions.
[x]   File: thali/thalireplicationmanager.js:L47-101
 It is generally considered best coding practice to avoid implementing the equivalent of case statements as nested if-then-elses. It is hard to read and keep track of state. A much cleaner solution, in my opinion, is to just use return statements. In other words
if (..deviceIdentityAvailable...) {
cb();
return;
}
if (...noDeviceIdentitySet...) {
stuff...
return;
}
if (...gettingDeviceIdentity...) {
blah...
return;
}
 Fixed. Will also use this format in the future.
[x]   File: thali/thalireplicationmanager.js:L148-166
 Shouldn't this code be hanging out with the rest of the identity set code? It's odd to separate them. But I realize this was probably a consequence of my comment about moving the require not being clear enough. Sorry. But could you please re-unite informDeviceIdentityListeners and clearDeviceIdentityListeners with getDeviceIdentity?
 Actually, Matt had all the external functions at the top followed by all the internal functions. So I was following that pattern. But I have reunited the functions now.
[x]   File: thali/thalireplicationmanager.js:L148-166
 Wouldn't it be easier to just set this._deviceIdentityListeners = []?
 Learned a new thing today :). Also removed the function as it only has one line now.
[x]   File: thali/thalireplicationmanager.js:L43-136
 All switches should always have a catch to find errors. Can you please put in a return on line 66 and then put in a throw if we get past line 67?
 Fixed.
[x]   File: thali/thalireplicationmanager.js:L43-136
 I have several suggestions here.

I would suggest that when getDeviceIdentity is called above and you end up in line 66 that you immediately just add cb to _deviceIdentityListeners. Otherwise you end up with the code below where you have to remember (in two different places) to call informDeviceIdentityListeners as well as to clean up the cb. If you just add cb to _deviceIdentityListeners then you won't have to remember anything.
Why do you set this_deviceIdentityListeners = [] on both 75 and 81? Since you have to do it in both places why not just set that line after line 83?
If you implement the two suggestions above then this function gets small enough that I would suggest just getting rid of it and putting the smaller code straight into line 61.

 I fixed #2 & #3. But I do not understand #1. I am already adding cb to _deviceIdentityListeners at line 66. Please clarify.
 Sorry, on comment 1 I meant line 61 not line 66! I had a typo.
 Fixed all 3.
[x]   File: thali/thalireplicationmanager.js:L43-136
 Now your state machine is stretched across two different places, getDeviceIdentity and here. Why would you do that? It just increases the probability of screwing something up. Wouldn't it be simpler to just call getDeviceIdentity and in the callback call startReplicationManager? Since start doesn't have a return value (it instead emits an event when things get going) it doesn't matter that you point an asynchronous call in here and it simplifies the heck out of your code.
 Fixed.
 Wouldn't it make much more sense to move this into the mockmobile file above and just take over storeGetDocumentsPathReturnArguments and GetDocumentsPath?
 Actually realized my mistake and fixed this before seeing the comment.
[x]   File: test/www/jxcore/test/mockmobilegetdocpath.js:L1-18
 Why are you using arguments? Why not just put errArg and fileLocationArg into the function signature?
 Fixed.
[x]   File: test/www/jxcore/test/pkcs12foldergood/.gitignore:L1-4
 I'm confused. Why would you need to tell the system not to ignore .gitignore? It wouldn't ignore it anyway?
 Will fix this when I use the global setup using tape.
 Deleted the ".gitignore" file as well as the folder "pkcs12foldergood".
[x]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-62
 You are assuming this location exists which it generally shouldn't since we have nothing to put in there and git doesn't record directories. Instead you should include a global setup using tape and just have it create the directory. Also please make sure to put in a global cleanup and have it delete the directory and its contents. You can use fs-extras-promise to handle the recursive delete.
 BTW, these setup/tear downs should be run after each test so you know you have a clean environment.
 This is not done yet.
 The folder where the pkcs12 file will be saved will be created before every test begins and deleted at the end of every test.
 :+1:
I'm closing this comment because I have a separate comment on how setup/teardown should happen.
[x]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-62
 How do you know that you are actually getting back the proper hash of a properly generated certificate? At a minimum you should read in the pkcs12 file yourself and run the hash function and compare the results so you can be sure.
 Fixed.
[x]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-62
 It's not safe to rely on test execution order. If the tests get moved around or the test running decides to run the tests in a different order (happens all the time) then this test will look like it passed but in fact it didn't do what you want. What you really need to do is first call the PKCS12 generation function yourself directly. Then read in the file and generate the hash. Then call getPublicKeyHash and makes sure it returns the same hash so you know it read the same document.
 Fixed.
[x]   File: thali/thalireplicationmanager.js:L43-126
 I think this code has a race condition.
Let's imagine that getPublicKeyHash fails.
So on line 70 we call all the registered CBs.
One of those CBs then immediately calls back into getDeviceIdentity to try again.
Their request will hit line 59 because we already set the flag to noDeviceIdentitySet, they will then have their CB pushed onto _deviceIdentityListeners in line 62 and then they will return when they hit line 63 because it's asynchronous.
At that point we return from line 70 and then call line 71 who immediately erases their enqueued CB.
This is the kind of heiseinbug that drives people insane.
Anytime you write Javascript code you have to always ask yourself "is my function giving up control to anyone else?" because the minute you do you have to think very carefully about re-entrant behavior.
I suspect the least mind bending behavior to fix this is to use something like slice() or equivalent to create a local copy of _deviceIdentityListeners, then set the global version to [] and then run get rid of informDeviceIdentityListeners (since you only use it one place) and just run the foreach that used to be in informDeviceIdentityListeners directly on the local copy. That should make everything work right even with re-entrant behavior. I think.
 Fixed as suggested.
[x]   File: thali/thalireplicationmanager.js:L43-126
 /unknow/unknown/
 fixed.
[x]   File: thali/thalicryptomanager.js:L1-114
 Although this use of module.exports is technically correct it is not idiomatic. When a module exports multiple functions this is usually handled by having each function individually declared using exports.x = function() (e.g. look at the Exporting a module section of http://www.sitepoint.com/understanding-module-exports-exports-node-js/). Please update accordingly.
The reason for this, btw, is to make it easy to intersperse exported code with non-exports content like purely local functions.
 Fixed.
[x]   File: thali/thalicryptomanager.js:L1-114
 We should never be exporting local variables. That just isn't right. At a minimum they should be wrapped in getter functions. But why are these here at all? Are you having binding problems? Is this for testing? Even for testing we should have setter wrappers with big warnings on them that they are only for testing purposes.
 These are local variables in cryptomanager.js that are needed when creating the pkcs12 package.
var pkcs12Content = crypto.pkcs12.createBundle(password, certname, country, organization);
But the same values are also needed by the test code for the test case "successfully read a previous pkcs12 file and return hash value". I will create getter functions for them.
 Done.
 Do we really need 7 getters who are only used for testing purposes? Doesn't that seem kind of extreme to you? How about a single function that returns an object with these values as members and is marked with a name like getConfigValuesForTestingOnly?
 Fixed by creating a single function.
[x]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-139
 What happens if there is an error? Since you are using the asynchronous version the Node.js docs say that the exception will be given to the callback. But there is no callback here. So it will silently fail. What you can do is instead use rmdirSync which should throw an exception if there is a problem.
 Used the "fs-extra-promise" package instead of "deleteFolder()" fn.
[x]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-139
 Wouldn't it be easier to write:

if (file) {
fs.unlinkSync(file);
}
fs.rmdirSync(fileLocation);
cb();

Normally, btw, using sync function is bad but in this case we are running a test framework which is inherently serial anyway, so it's o.k.

 Used the "fs-extra-promise" package instead of "deleteFolder()" fn.
[x]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-139
 Instead of creating this function wouldn't it be easier to use something like https://www.npmjs.com/package/fs-extra-promise? You can add it as a dev dependency in the package.json and just call remove? That function, btw, will handle cases where there is more than one file in the directory.
 Used the "fs-extra-promise" package.
[x]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-139
 Think of how ridiculously fragile this code is. Wouldn't it be vastly more robust if you had a setup and a tear down function like all test frameworks use? Now, just to confuse things, it turns out Tape doesn't support such an animal. But what then? The first thing a good dev thinks is - it's better to steal than borrow! So you whip our your handy search engine and pretty quickly you find:
https://github.com/isaacs/node-tap - It has a teardown function. Which is good. But it's sorta different than our current test framework. And I don't want to change things that much.
https://www.npmjs.com/package/wrapping-tape - Good license. It's old but it does something simple and I happen to know the dev who wrote it (he's the leader of PouchDB) and he is solid. This requires wrapping the tests in thalicryptomanagertests.js inside the require but that's super easy.
https://www.npmjs.com/package/redtape - This looks reasonable but it seems fancier than we need, wrapping-tape seems easier.
https://www.npmjs.com/package/tapes - This does the job quite nicely but it would require changing our tests to make them nested. That isn't a big deal, not much work and it has a good license but again it's a bit more involved than I like.
My personal vote would be for wrapping-tape.
Of course the other option would be to have just written this all yourself. Wrapping-Tape, for example, consists of exactly one file that is 37 lines long. See https://github.com/daleharvey/wrapping-tape/blob/master/wrapping-tape.js so even implementing this ourselves in a slightly slick way would have been no big deal.
But in any case we shouldn't try to do this kind of error handling where we try to find all the exit points and stick in our cleanup code. That is just too error prone. So please give wrapping-tape a try and please clean up the tests.
 Used wrapping-tape for setup/teardown activities.
[x]   File: thali/thalicryptomanager.js:L1-127
 Why would you change the function name? Why not just export generatedSlicedSHA256Hash directly? What was the motivation?
 If I just export generatedSlicedSHA256Hash(), it cannot be called by the other exported fn getPublicKeyHash(). So I came up with getSlicedSHA256Hash(). Another way to fix this is to make cryptomanager a new type and then use "this" to call generatedSlicedSHA256Hash().
 You just change the call in getPublicKeyHash to call exports.generateSlicedSHA256Hash. There is nothing magic about exports. It's just an object and generateSlicedSHA256Hash is just a property of that object. So you can call it like any other property on any other object.
 Fixed.
[x]   File: test/www/jxcore/test/thalicryptomanagertests.js:L1-131
 I'm confused by lines 42 through 45. Aren't your effectively just re-inventing t.error? I am assuming that when you use a framework you go read all the instructions about that framework. So didn't you go to https://www.npmjs.com/package/tape and look at what methods it supports and see which ones already do what you need?
 Used tape's "error()" and "ifError()" where appropriate.

Learned a new thing today :). Removed the function as it only had one line.

:shipit:

This PR got too messy so @srichal submitted another one that just included the final changes. We are closing this PR in favor of that one.


Intellisense does not work for Javascript in Polygot notebook

I am writing to bring to your attention a feature request that, I believe, will significantly enhance the utility of the Polyglot Notebook, especially for JavaScript developers like myself. The current lack of Intellisense support for JavaScript in the notebook is a limitation that affects the coding experience and productivity.

I think your Polyglot Notebook is contributed by an extension, so I suggest you raise the issue with the extension authors.


EDU-724 Create multitrack media player

Closes https://educandu.atlassian.net/browse/EDU-724

In edit mode, when we switch sourceType the sourceUrl is also reset, but the mixer still shows the old data

Such a cool and fun plugin 😍 Good job!

Small UI suggestion, if you feel it would be better, would be to write the times on the right hand side of the bar (as they represent the length, they might be more intuitive if placed there):

Not sure about the case of overflow to the right, if times should overflow a bit too:

In edit mode, when we switch sourceType the sourceUrl is also reset, but the mixer still shows the old data

I'd like to fix this (and other issues in this panel) with https://educandu.atlassian.net/browse/EDU-761 as I think we might want to change the way the track lengths are determined there anyway.

Such a cool and fun plugin heart_eyes Good job!

Thanks a lot :smile:


Add token avatar

Overview
This PR implemented an endpoint token.upload_avatar for providing a way to upload token's avatar
Changes

Added an endpoint token.upload_avatar to router
Added field avatar to schema.
Added AddAvatarToTokens migration script.

Implementation Details
Everything is the same to account.upload_avatar.
Usage
Try uploading an avatar with Postman or something.
token.upload_avatar
{
  id: "tok_BTC_1234",
  avatar: <binary>
}

Impact
Run ecto.migrate to add avatar field to token table.
Todo

[x] Add tests

Oh, no tests yet...

Can you link this PR to the original issue?

Ideally this also should reflect and merged after #730.

[ ] Wait for #730 to be merged
[ ] Update this PR's permission checking to #730's way.


Necmettin Erbakan University

E-Mail Domain for Academic Members

@hakyurek Pull request merged. Thank you!


multilingual and custom controller

Laravel Version: 5.4
Voyager Version: 0.11
PHP Version:5.6.30

Description:
I wrote a custom controller and edit-add.blade and everything is working fine, except for translation.
Things go wrong in multilingual.js I debugged the javascript and for some reason $_val = undefined when submitting. Posting the translation array with a missing translation 'question1_i18n' => '{"nl":"zon","de":"zon"}', resulting in an Undefined index: en  at the server side.
After some debugging I see things go wrong in de following piece of code at multilingual.js:188
            updateInputCache: function(inp) {
                var _this  = this,
                    inpUsr = inp.data('inpUsr'),
                    $_val  = $(inpUsr).val(),
                    $_data = {};  // Create new data

I'm not sure where inpUsr is coming from. Maybe I'm missing some magic somewhere. I stripped a lot of the stuff used in the bread controller and am using plain eloquent instead of the dataTypeContent way of passing stuff. Is that a problem?
Can somebody kick me in the right direction?

Hello.
You did hit a bug, if you choose a default language other then en, system will break.
There's a missing feature for setting up the default language, we will write a Command for that.
Important note
Let's suppose your default language is nl for the next examples.
Multilingual will save the default language data at the main table, so, using pages table as an example, system will write nl records at pages table, and the de at the translations table, respectively.
Workaround

at voyager config, make sure you have the default language setup to nl.

open the translations table, you should only see the de records, if you don't find them, try using the system updating a record and watch for changes, it should work.

If none of this helps, I suggest you to add the en language back to the system, and wait for a update that will fix that.
Happy coding!

Thanks, for looking into it. But that's not the problem. I have en as default language and when I use the breadcontroller things work fine.
It's only when I use my own controller, when debugging I got stuck at inp.data('inpUsr') I guess the data attribute should be written in the dom by something, but I can't discover what.

If you have 2 languages available nl and de, then en should not be the default language for the multilingual system. Anyway, it's strange if it works :D
I suggest you to follow the Post.blade, it's using a custom view and you can follow the logic.
Good luck.

Just to set it straight I have 3 languages and en is the default. The problem was that the selected language was not submitted. So instead of {"en":"sun", "nl":"zon", "de":"zon"} this was submitted {"nl":"zon","de":"zon"}
Just found the problem, I had the label between the hidden translation fields and the input fields
And now I see inpUsr.data is filled in the refresh function, dunno how I missed that...
Anyway it's working now I moved the label out of the way like this
<label for="name">Question</label>
@include('voyager::multilingual.input-hidden', [
    '_field_name'  => 'question1',
    '_field_trans' => get_field_translations($question, 'question1')
])
<input type="text" class="form-control" id="question1" name="question1" placeholder="question"
    value="@if(isset($question->question1)){{ $question->question1 }}@endif">

Closing issue since its fixed.


Integration Studio Automatically Update not working

Description:
Automatic update is not starting when tool is running

Fixed in the latest 720 release

Fixed in the latest 720 release


For weird reasons "sliderView.setImageDrawable" doesn't work for a release buidType.

setImageDrawable( ) works fine with debug buildType, but displays a blank white view in a release APK.
setImageByte( ) seems to work but UI first freezes for like 4 sec especially when loading it from another activity.
I'm therefore left with setImageUrl( ) as the only option.

setImageDrawable( ) works fine with debug buildType, but displays a blank white view in a release APK.
setImageByte( ) seems to work but UI first freezes for like 4 sec especially when loading it from another activity.
I'm therefore left with setImageUrl( ) as the only option.

Checkout new version , in 1.3.0 you can create a slider adapter like recycler view, it gives you more coding flexibility to load images or adding multiple layouts in sliderview.


fix bug the 'codegen' dir create after the first _ops.txt store

Thanks @rkimballn1 to help figure out this.

@csullivan I can not reproduce the issue. the gpu_codegen is generated without problem after delete.
Let's sync the details offline.


Add repr for Unset

Closes #508
Add repr for Unset, so models that include this value display appropriately

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.35%. Comparing base (e185578) to head (4414a77).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #514   +/-   ##
=======================================
  Coverage   94.35%   94.35%
=======================================
  Files           7        7
  Lines         780      780
=======================================
  Hits          736      736
  Misses         44       44

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Boolean custom field value converted to float on indexing

Description

In our Shopware setup, we have a custom field configured with type bool. This custom field will be used in products.
When a product is being indexed that contains a custom field of type bool, this bool value will be converted to a float because of this piece of code:
private function formatCustomFields(array $customFields): array
{
    foreach ($customFields as $name => $customField) {
        if (\is_int($customField)) {
            $customFields[$name] = (float) $customField;
        }
    }

    return $customFields;
}

in \Shopware\Elasticsearch\Product\ElasticsearchProductDefinition
Possible Solution

When looping true the custom field values, check the type of the custom field for each value to make sure a correct conversion is done for the value.
Additional context

Value of custom fields on a product:
{
    "fsc": 1,
    "media_packshot_6": null,
    "media_packshot_7": null,
    "media_packshot_8": null
}

When this product is being indexed, following error occurs:
[app] failed to parse field [customFields.fsc] of type [boolean] in document with id '57a1f0ec0373491b9178ced49bdb5c41'. Preview of field's value: '1.0'

Is fixed with https://github.com/shopware/platform/commit/069dda4ba3447734ca6cb5f98338805bf1a5dffa


chore: set imagePullPolicy for initContainer

As already for the main container the case - the initContainer should also receive the imagePullPolicy value
https://github.com/eclipse-tractusx/daps-helm-chart/blob/5e25c56df1d66433f84217794fcc443a252e312a/charts/daps-server/templates/deployment.yaml#L98-L103

Marco Lecheler<EMAIL_ADDRESS>Mercedes-Benz Tech Innovation GmbH (ProviderInformation)

@wjost please ask someone from your team for a review of this PR, thanks!

You need to define it in deployment.yaml like this
imagePullPolicy: {{ .Values.init.image.pullPolicy }}
And also you need to define a separate tag in values.yaml with respect to init image.
Something like this:
init:
image:
# -- Init container image
repository: "alpine"
# -- Image pull policy
pullPolicy: Always
# -- Image tag. Overrides the image tag whose default is the chart appVersion.
tag: "3.17.3"
-- Pod security context configuration
securityContext:
# capabilities:
#   drop:
#   - ALL
# readOnlyRootFilesystem: true
# runAsNonRoot: true
# runAsUser: 1000

@adkumar1 This is related to PR #14 where I try to change the initContainer image (see: PR14-diff).
If this will be approved another key for the initContainer should not be required right?
It is more resource-efficient and easier to use the same image here instead of using another (small alpine) image.

Note: 4a2542b - resolved merge conflict by merging main branch into PR branch chore/initcontainer-imagepullpolicy

Change looks good

There are still merge conflicts on this branch.

@fty4 : Please fix conflicts

@adkumar1 / @wjost  merge conflict are solved


'User genome list' option for Compare Regions tool

Hi, Bob, I fully realized how overbooked you are...  Sorry to be adding to your load...  but maybe you could find time to add an option "user genome list" to your great new Compare Regions tool?  It would be hugely useful (for example, just during this last Workshop two users I talked to could have really benefited from it)

2+
Several users in the Germany workshop also wanted the same function.
-Maulik
Sent from my iPhone

On Aug 18, 2017, at 2:20 AM, Sveta-user<EMAIL_ADDRESS>wrote:
Hi, Bob, I fully realized how overbooked you are... Sorry to be adding to your load... but maybe you could find time to add an option "user genome list" to your great new Compare Regions tool? It would be hugely useful (for example, just during this last Workshop two users I talked to could have really benefited from it)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


npm install fail on node5.11

Downloading zookeeper-3.4.3 from http://apache.mirrors.tds.net/zookeeper/zookeeper-3.4.3/zookeeper-3.4.3.tar.gz
tar: Unrecognized archive format
tar: Error exit delayed from previous errors.
Unable to build zookeeper library
make: *** [.] Error 1
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:100:13)
gyp ERR! stack     at ChildProcess.emit (events.js:185:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:204:12)
gyp ERR! System Darwin 15.4.0
gyp ERR! command "/usr/local/Cellar/node/5.11.0/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/john/Projects/node-zk-browser/node_modules/zookeeper
gyp ERR! node -v v5.11.0
gyp ERR! node-gyp -v v3.3.1
gyp ERR! not ok
npm info lifecycle<EMAIL_ADDRESS>Failed to exec install script

Can you try to install like this npm install node-zookeeper@latest? I'm working on fixing the default version fixed soon.

thx,it worked


Pipfile in home directory confuses Pipenv

Be sure to check the existing issues (both open and closed!), and make sure you are running the latest version of Pipenv.
Check the diagnose documentation for common issues before posting! We may close your issue if it is very similar to one of them. Please be considerate, or be on your way.
Make sure to mention your debugging experience if the documented solution failed.
Issue description
If there is a Pipfile in your home directory, pipenv will create a new environment named after your home directory.
Expected result
I expect pipenv to create the new environment based on the current directory name
Actual result
Wrong pipenv directory created
Steps to replicate
A) Start with a user error -- running pipenv shell in your home directory
$ cd
$ pwd
/home/chris
$ pipenv shell --python `pyenv which python`

Now there's a Pipfile at /home/chris/Pipfile
B) Start a new terminal, so everything is clean, and try to create a new environment
$ mkdir abcd
$ cd abcd
$ pipenv shell --python `pyenv which python`
Launching subshell in virtual environment...
 . /home/chris/.virtualenvs/chris-305vt3Nc/bin/activate
chris@chi ~
$  . /home/chris/.virtualenvs/chris-305vt3Nc/bin/activate
(chris) chris@chi ~

Note that the virtualenv that was created is for "chris" not for "abcd".  And this is done without warning.

Please run $ pipenv --support, and paste the results here. Don't put backticks (`) around it!   I am not sure what the desired change would be honestly.  You can run pipenv --rm in your home directory to clean up that issue as it currently stands.

oh well.  I guess I was hoping for the "Principle of Least Surprise".

@ccurvey Well I mean the issue doesn't have to be closed -- if you or someone has an idea for how we can improve the experience then let's do it.

note to self.    If by accident, you create an environment in your home directory, use pipenv --rm to get rid of all the files related to that environment.


feat: dynamic shapes support for neg ops

Description
Add test case for dynamic shape input of aten.neg ops
Replaced output_dtypes arg in run_test_with_dynamic_shape() with check_dtype to handle
integer type of dynamic shape input test case.
Fixes # (issue)
Type of change

New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines of this project (You can use the linters)
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas and hacks
[ ] I have made corresponding changes to the documentation
[x] I have added tests to verify my fix or my feature
[x] New and existing unit tests pass locally with my changes
[x] I have added the relevant labels to my PR in so that relevant reviewers are notified

Changes for random integer caused failure in arange/cos/sin test. I think it unmasked potential issue as all input values were zero.
I will submit separate PR to address it.


missing module "optutils"

Hi, thank you for the code, I have already trained some models and would like to visualize the results. However, the scripts visualize_latent_space.py and visualize_sequence.py are trying to import the module optutils, which seems to be missing from the repository. Could you please add this module?

Hi @gabinsane,
If you want to view the results, please follow the instructions in the README.md file.
This command will generate rows and columns of stick figures.
python -m src.visualize.visualize_checkpoint PATH/TO/CHECKPOINT.tar --num_actions_to_sample 5  --num_samples_per_action 5

Or if you want to generate meshes, you must first generate the sequences in .npy data:
python -m src.generate.generate_sequences PATH/TO/CHECKPOINT.tar --num_samples_per_action 10

and then use this script to render:
python -m src.render.rendermotion PATH/TO/generation.npy

The scripts visualize_latent_space.py and visualize_sequence.py are leftovers, so their use is deprecated. I will remove them soon.


As a trainer, I want to be able to use training template when creating a training

[x] #296
[x] #298
[x] #299
[x] tests

Client has accepted the story


Update Default runtime to node16

Node 12 has an end of life on April 30, 2022.
This PR updates the default runtime to node16, rather then node12.
This is supported on all Actions Runners v2.285.0 or later.
Description:
Describe your changes.
Related issue:
Add link to the related issue.
Check list:

[ ] Mark if documentation changes are required.
[ ] Mark if tests were added or updated to cover the changes.

https://github.com/actions/setup-java/releases/tag/v3.0.0 lists this as a “breaking change” but does not really explain how you would know whether or not you need to pay attention. For someone encountering this update with no further context in a Dependabot bump of the action (https://github.com/jenkinsci/cloudbees-folder-plugin/pull/217 for example), it is hard to tell whether or not it would be safe to apply.

This is supported on all Actions Runners v2.285.0 or later.

implies that workflows using GitHub-supplied runners would be unaffected and only people using self-hosted runners need care, but I am just guessing here.


Inaccurate 'Can only affect your own account' error

Steps to reproduce

[x] Tell us what broke. The more detailed the better.
[ ] Include the feathers-gen-specs.json file from your app.
[ ] Include the src/services/[serviceName]/[serviceName].schema.?s files if the issue involves the fields in one or more services.

I verified that password change is sending the correct user, auth token and such down to the server. Then on this line
the authUser Id and the user1 (from the db) id are identical, but using === directly on them still returns false.
Changing this line to stringify the ids fixes the issue
  if (options.ownAcctOnly && authUser && (`${getId(authUser)}` !== `${getId(user1)}`)) {

It might also make sense to do this in the get-id helper?

Thanks for the catch!
Did you use Mongoose or MongoDB? The keys would be ObjectIDs in that case.
getId now does a .toString() on the key.
Please remember this repo has not yet been released. Beaking changes are likely and I push changes to master directly so there are no PRs to look at.


Fix: make _stats_available on Hawkular object

https://github.com/ManageIQ/wrapanapi/pull/64 introduced this issue.

Lint report for commit bb63e92bceb7abaf5943f9a596e5c9ebd09b8ee2:
Everything seems all right from lint perspective :smile: .
Commit inspection report:
No commit flaws detected.

CFME QE Bot


Add option for compressed images in jump_portrait

@afermg for review, but let's not merge it until the compressed images are uploaded onto s3 and the file structure, etc, is finalized

Sounds good to me. Let me know when it is functional.

Could you change the branch to merge into to be "portrait". Just to keep our monorepo "main" clean between module versions.

Closing in favor of #32


[WIP] OP Fault Proof Dispute Game implementation for op-verifier and op-gateway

On March 19, 2024, Optimism initiated a significant upgrade on the Optimism Sepolia network to introduce a fault-proof system. Unfortunately, this upgrade broke the functionality of the op-verifier and op-gateway components of the ENS EVM Gateway. Below is an overview of the upgrade's key points.

The L2OutputOracle is being entirely removed and replaced by the OptimismPortal and DisputeGameFactory. The L2OutputOracle smart contract is currently used by the trusted Proposer role to store L2 state output proposals. Presently, developers use these outputs to prove that their withdrawals actually happened on L2. But with fault proofs, developers will have to change how their client software proves withdrawals in the first step of the two-step withdrawal process.

Reference: https://docs.optimism.io/builders/notices/fp-changes#overview-of-changes
You can see proof on Etherscan that L2OutputOracle has ceased on Optimism Sepolia: https://sepolia.etherscan.io/address/0x90E9c4f8a994a250F6aEfd61CAFb4F2e895D458F
Despite the lack of documentation on upgrading from L2OutputOracle to DisputeGameFactory, we have reverse-engineered the Optimism code and implemented the necessary upgrades to the op-verifier and op-gateway in this pull request. Here is a summary of the changes introduced:

L2OutputOracle
DisputeGameFactory

l2OutputIndex
disputeGameIndex

getL2Output(...)
gameAtIndex(...)

outputRoot
gameProxy.rootClaim().raw()

latestOutputIndex()
gameCount() + findLatestGames(...)

outputProposal.l2BlockNumber
disputeGame.l2BlockNumber()

To facilitate a smooth transition, it's crucial to incorporate an activation point system into the op-verifier smart contract. Moreover, to ensure our gateway remains adaptable to future updates, the op-verifier contract should be designed with an upgradeable pattern. However, it's been observed that the EVM Gateway is intended to be immutable, leading us to forego these enhancements for the EVM Gateway. Should you be interested in exploring the implementation of an activation point or an upgradeable smart contract, please let us know.
We have already applied the upgradeable design pattern to all contracts within our Opti.Domains CCIP Gateway and plan to introduce an activation point to our Opti.Domains CCIP Gateway shortly. This approach will enable us to upgrade without disrupting the user experience.
The source code for Opti.Domains CCIP Gateway is available at: https://github.com/Opti-domains/optidomains-ccip-contracts
The Opti.Domains team is eager to continue contributing to developing and maintaining the Optimism verifier and gateway implementations.
The integration of the fault-proof system is scheduled to merge into the Optimism Mainnet in Q3 2024.
Note: This is a work in progress and is not fully tested.

Please let me know when this is ready for review again!

It should be ready to review. However, let's review this sub PR first: https://github.com/ensdomains/evmgateway/pull/37

Test domain name: disputegame.eth
Name hash: 0x438bfe3fc990665148f8ac1638323ab84054a5c22a1ab61fe63cebc3040129cb
DNS encoded: 0x0b6469737075746567616d650365746800
L1 Resolver: https://sepolia.etherscan.io/address/0x4fAA6228c0EACE916d734F76B56551770176E7D9
Gateway: https://op-gateway-worker.optidomains.workers.dev/{sender}/{data}.json
L2 Resolver: https://sepolia-optimism.etherscan.io/address/0xF079f2A30f3c797f8e6920ad783b74846a9acBf4#readContract
L2 Resolver Factory: https://sepolia-optimism.etherscan.io/address/0x13950e8d21fc50c02036e0152d77df692fc8edfa

Hi @Arachnid following #37 I have made a PR to ccip-read to patch REDACTED case that https://ccip-v2.ens.xyz is sending as a sender. It would be great if we can get this merged and published to the NPM registry so that ENS UI can work with this gateway implementation correctly.

I have pushed a temporary fix for Cloudflare "The script will never generate a response". It works with the official ENS UI after deploying this fix.

This removes the use of the app global variables. Changing global variable to server will not resolve this issue; we need to completely avoid using global variables.
However, this is not a good fix. We need to think of a more elegant way.

Should I merge this PR: https://github.com/ensdomains/evmgateway/pull/34 before continuing the development?

That PR is now merged, so please go ahead.
Can you explain why you think the global variable is causing your issue with REDACTED? This seems to be purely a logging issue and not anything that affects the actual operation of the service.

As per my temporary fix, I have commented server global variable and rebuilt server instance on each request and it fix the issue.
Also this blog: https://zuplo.com/blog/2022/03/04/the-script-will-never-generate-a-response suggests a similar cause about the use of global variables.

This is strange, because app/server isn't a promise here, it's a lazily initialized variable. The longer-term solution, however, is likely to be optimizing imports so that we don't hit the startup time limit in the first place.

I'm assuming I should start over from the main branch and incorporate diff...

Yes please!

@Arachnid I have updated the implementation in #45


Make the Shell enum non-exhaustive

(sorry for not using the template, but I don't think it's applicable here)
Currently, the clap::Shell enum (as defined here) can be matched against, which means that supporting a new shell is a breaking change. I'd like to propose making the enum nonexhaustive. Until rust-lang/rfcs#2008 or an equivalent gets passed and stabilized, this would be done through a doc hidden __nonexhaustive_dont_match variant (or similar). Using that variant would be considered unsupported, and the existing enum functions would ignore it (or panic if passed in). This would be a breaking change, but it would prevent future breaking changes whenever a shell is added.
It's unfortunate this didn't happen with clap v2. I'm not sure if this would be a major enough change to warrant waiting for clap v3, that'll be up to the maintainers of course.

Since I'm actively working on v3 (see v3-master branch) I can just incorporate this into the new version. Actually I'm trying to pull out all the completion code into clap_completions so that changes such as this can be breaking and bump the major without changing clap proper.
Sorry for the long wait on a response :\

Oh and no worries with the template. If it doesn't apply, no need to use it :wink:

Implemented on v3-master


to_input(...) doesn't have east, west... properties

I would like to connect the input image to conv blocks and other blocks, but it is not possible since to_input(...) doesn't have east, west, northeast, etc... properties. How to solve this? Maybe wrap to_input(...) in a box or something?

i have the same issue, please any help¿?

@rafariva, there is a way: describe your model directly in latex syntax (no python wrapper) and plot an invisible box over the input layer, then you can connect arrows to that invisible box.

Please, can you send us an short example?

@rafariva, I don't have an example specific for this. You could just follow this: https://github.com/HarisIqbal88/PlotNeuralNet/blob/master/examples/fcn8s/fcn8.tex
Once you get the syntax, it is not difficult

Thant 4 u help


iconv linker errors on OSX

In particular, I'm running from the Atom IDE engine.
The Atom integration invokes this command:
/Users/aesa/Code/Nix/haskell-ide-engine/.stack-work/install/x86_64-osx-nix/lts-11.17/8.2.2/libexec/x86_64-osx-ghc-8.2.2/cabal-helper-<IP_ADDRESS>/cabal-helper-wrapper \
"--with-ghc=/nix/store/akpfx4dwldj6s6rvnamnc24lkaxgrhl2-ghc-8.2.2/bin/ghc" \
"--with-ghc-pkg=/nix/store/akpfx4dwldj6s6rvnamnc24lkaxgrhl2-ghc-8.2.2/bin/ghc-pkg" \
"--with-cabal=cabal" \
"/Users/aesa/Code/Katas/Day19" \
"/Users/aesa/Code/Katas/Day19/.stack-work/dist/x86_64-osx-nix/Cabal-<IP_ADDRESS>" \
"package-db-stack" \
"flags" \
"compiler-version" \
"ghc-merged-pkg-options" \
"config-flags" \
"non-default-config-flags" \
"ghc-src-options" \
"ghc-pkg-options" \
"ghc-lang-options" \
"ghc-options" \
"source-dirs" \
"entrypoints" \
"needs-build-output"

The corresponding output from that operation is:
Linking /Users/aesa/.cache/cabal-helper/cabal-helper<IP_ADDRESS>-Cabal<IP_ADDRESS> ...
clang-5.0: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
clang-5.0: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
      _hs_iconv in libHSbase-<IP_ADDRESS>.a(iconv.o)
     (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding_closure, _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding14_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding10_closure , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding10_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding14_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding13_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure )
  "_iconv_open", referenced from:
      _hs_iconv_open in libHSbase-<IP_ADDRESS>.a(iconv.o)
     (maybe you meant: _hs_iconv_open)
  "_iconv_close", referenced from:
      _hs_iconv_close in libHSbase-<IP_ADDRESS>.a(iconv.o)
     (maybe you meant: _hs_iconv_close)
  "_locale_charset", referenced from:
      _localeEncoding in libHSbase-<IP_ADDRESS>.a(PrelIOUtils.o)
ld: symbol(s) not found for architecture x86_64
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
`cc' failed in phase `Linker'. (Exit code: 1)

Worth Noting:
iconv --version
iconv (GNU libiconv 1.11)
Copyright (C) 2000-2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Bruno Haible.

And iconv is installed under /usr/bin/iconv
I guess it came with the system?

I've also come across this stack overflow thread.
https://stackoverflow.com/questions/43359289/architecture-x86-64-while-running-haskell-code-haskell-osx-iconv
However, I don't know how to determine where the other libiconv dependencies are, other than the binary.
Thanks in advance

I've also followed along with the suggestions put forth in this issue thread
https://github.com/commercialhaskell/stack/issues/825
But to no avail. /:

👍
Having exactly the same issue with Nix 2.1, from which I've installed stack and cabal-install, and used them to build haskell-ide-engine from source, on macOS 10.13.6.

I've also come across this (all the way back from 2011)
http://blog.omega-prime.co.uk/2011/01/28/solving-ghc-iconv-problems-on-os-x-10-6/
But I was also not able to replicate the fix.

@AesaKamar Can you check that /usr/lib/libiconv.dylib exists? And if it does that nm /usr/lib/libiconv.dylib  | grep _locale_charset returns some address?

FWIW, not directly related to haskell-ide-engine, but I've been having trouble building anything with cabal after installing it with Nix, and just got it working by introducing a -liconv to the build command. Adding this to my cabal file worked:
  extra-libraries:     iconv


ValueError: The number of GPUs per node is not divisible by the number of tensor parallelism.

I have 3 GPUs (3x3090). When I try to load LLaMA-2-13B and set the tensor_parallel_size to 2 it gives me this error. When I set it to 3 error follows like ValueError: Total number of attention heads (40) must be divisible by tensor parallel size (3).

The same problem, a node with 8 V100 graphics cards, try to run LLaMA 2 70B with 5, and report the same error. Frankly, it doesn't make sense and is a waste.

I cannot reproduce this bug on my side. Can you share the code and more details about your environment that can reproduce the error?

I try to run with 3 GPUs I get this:
  File "/usr/local/lib/python3.10/dist-packages/vllm/entrypoints/openai/api_server.py", line 616, in <module>
    engine = AsyncLLMEngine.from_engine_args(engine_args)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 486, in from_engine_args
    engine = cls(engine_args.worker_use_ray,
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 270, in __init__
    self.engine = self._init_engine(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 306, in _init_engine
    return engine_class(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 95, in __init__
    self._verify_args()
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 185, in _verify_args
    self.model_config.verify_with_parallel_config(self.parallel_config)
  File "/usr/local/lib/python3.10/dist-packages/vllm/config.py", line 118, in verify_with_parallel_config
    raise ValueError(
ValueError: Total number of attention heads (64) must be divisible by tensor parallel size (3).

you must set the parallel size to divisor of the number of attention heads，if it's 64 , please try 2, 4, 8 etc.

you must set the parallel size to divisor of the number of attention heads，if it's 64 , please try 2, 4, 8 etc.

why？

Because the heads dimension is the one that is split across the tensor parallel workers.
i.e. you can't split 64 heads evenly across 3 GPUs.

maybe we need some method to manually split the tensor, not just divided it.

@hmellor Could you please explain the reason as to why spreading heads evenly matter? This might be a dumb question, so if you could point me to resources, please do.

@SMAntony  pytorch do not support... if you want to use the pytorch's tensor parallel, must ensure the tensor can be divided evenly.


Mawego IQCare V4 Migration to V6 Error Log

MawegoMigrationLog - Error.txt

Still has an error:
MawegoMigrationLog - Error 2.txt


Added media option to box.

This PR aims to add the media option to Box component. This means that the box now can be hidden/visible for specific breakpoints.
For example:
This box
<Box  media="palm"></Box>

Will only be visible for palm size devices.
Similarly,
This box
<Box  media="lap-and-up"></Box>

Will only be visible for table-size and bigger.

Can you remind me what specific example caused us to pursue this?

Original motivation was the ability to show/hide items depending on the resolution. There are some scenarios where we want to hide elements on mobile. Or some cases where we want to show items in mobile.
I was doing that inside my Sass file. We discussed about different way of doing this: visibility hidden, opacity zero...
I believe this PR facilitates this feature by adding a property to the box.

On Aug 17, 2015, at 5:03 PM, Eric Soderberg<EMAIL_ADDRESS>wrote:
Can you remind me what specific example caused us to pursue this?
—
Reply to this email directly or view it on GitHub.

I'm trying to remember a specific screen where we needed it. I'm just wanting to make sure as it feels like we're slowly exposing more CSS stuff in Box.

Note applicable anymore.


WIP: Hoststatus remove stats creation.

Work in progress to remove stats creation from HostStatus.

[approve ci rocky]

[approve ci rocky]

https://github.com/apache/trafficserver/pull/8694 should fix the autest. Once it's merged into 10-Dev you can rebase.

[approve ci autest]

[approve ci autest]

[approve ci fedora]

[approve ci autest]

[approve ci Fedora]

[approve ci fedora]

@brbzull0 I've added in the persistence.  You'll see that I added back in the HostStatus call in traffic_server.cc with the new HostStatus::loadFromPersistentStore() function

[approve ci clang-analyzer

[approve ci clang-analyzer]

[approve ci fedora]

@jrushford this looks good, just have a question.
Do you think you will be injectingthe host_records.yaml into traffic_server through the JSON-RPC node?(by using traffic_ctl or any other tool). If this is the plan at some point maybe the field names in the rpc request and the dump host_records.yaml file should be the same in order to re-use them.

@jrushford this looks good, just have a question.
Do you think you will be injectingthe host_records.yaml into traffic_server through the JSON-RPC node?(by using traffic_ctl or any other tool). If this is the plan at some point maybe the field names in the rpc request and the dump host_records.yaml file should be the same in order to re-use them.

@brbzull0 I didn't have any plans to use the JSON-RPC node to inject them but, that could be useful. In this PR, the host_records.yaml is loaded at startup by trafficserver.  However, I'll take a look and make sure that the names are the same, someone might have a use case for the injection.

Looks good to me, let's see what Damian says.

[approve ci fedora]

[approve ci fedora]

[approve ci]

@brbzull0 and @ywkaras any more changes?  Are you ok with the const & removal?

Looks good to me.


request help: The APISIX dashboard should have its own independent docker image

Issue description
First of all, the dashboard should not be deployed on the forwarding node, but to expose services through a route (ingress)
Secondly, Skywalking and Kong, etc., their dashboard images are independent.

Environment

apisix version (cmd: apisix version):
OS:

We have Dockerfile for Dashboard Next now according to this issue :) but not on Dockerhub currently 🤔
https://github.com/apache/incubator-apisix-dashboard/issues/155


Is it possible to set a models relationship before saving to database?

I have a model that is related to a team. When submitting a new create request for a model with a relationship it initially saves the record without the team_id being set. My database structure does not allow the field to be null and this causes a error.

Never mind. It looks like I forgot to set the relationship on my hydrator.

No problem glad you figured it out. Sorry the documentation isn't complete at the moment.

No problem on the documentation. The package is great so far and saved me tons of work.


TypeError: Cannot read property 'thresholds' of undefined

I'm submitting a ...

[x] Bug report
[ ] Feature requestdd
[ ] Question / Support request

For bug report please include this information:
Software Versions

Grafana
Zabbix
Grafana-Zabbix Plugin

v 5.0.0 (commit: af6e283)
3.4.6
3.9.0

#### What did you do?
Installed grafana, installed Zabbix plugin. Im use standart dashboard "Zabbix System Status", open and i cant see "thresholds" like this:

i get this error:

Is this a plugin bug or my mistake?

Yes, seems, this is caused by new panel format in Grafana 5.

Seems, it's related to #556. After update to version 3.9.1 this should work.


Problems when using with NX monorepo

Bug Report
Describe the bug
Failing to compile with just a basic library generated.
To Reproduce
Please try to build a small repo with a repro of your problem and provide a link to it.
Doing that allows more people to quickly help you.
If you can't provide a repo then provide clear steps describing how to reproduce the issue.

yarn create nx-workspace
Enter a workspace name
Select empty workspace
npm i -g @nrwl/cli
yarn add -D @nrwl/react
nx g @nrwl/react:lib test
nx g @nrwl/react:component --project=test button
Add the following mdx next to the button component file

---
name: Button
route: /
---

import { Playground, Props } from 'docz'
import { Button } from './'

# Button

<Props of={Button} />

## Basic usage

<Playground>
  <Button>Click me</Button>
  <Button kind="secondary">Click me</Button>
</Playground>

yarn add -D docz@next
Run npm run docz dev
See the errors in the console

Building app
warn Configuring yargs through package.json is deprecated and will be removed in the next major release,

 ERROR #10226  CONFIG

Couldn't find the "gatsby-plugin-emotion" plugin declared in "/Users/michael/Projects/coolfire/coolfire/node_modules/gatsby-theme-docz/gatsby-config.js".

Tried looking for an installed package in the following paths:
 - /Users/michael/Projects/coolfire/coolfire/node_modules/gatsby/dist/bootstrap/load-themes/node_modules/gatsby-plugin-emotion
 - /Users/michael/Projects/coolfire/coolfire/node_modules/gatsby/dist/bootstrap/node_modules/gatsby-plugin-emotion
 - /Users/michael/Projects/coolfire/coolfire/node_modules/gatsby/dist/node_modules/gatsby-plugin-emotion
 - /Users/michael/Projects/coolfire/coolfire/node_modules/gatsby/node_modules/gatsby-plugin-emotion
 - /Users/michael/Projects/coolfire/coolfire/node_modules/gatsby-plugin-emotion
 - /Users/michael/Projects/coolfire/node_modules/gatsby-plugin-emotion
 - /Users/michael/Projects/node_modules/gatsby-plugin-emotion
 - /Users/michael/node_modules/gatsby-plugin-emotion
 - /Users/node_modules/gatsby-plugin-emotion
 - /node_modules/gatsby-plugin-emotion

not finished open and validate gatsby-configs - 0.567s

after installing gatsby-plugin-emotion the error comes from it trying to compile my README.md file.
Building app
warn Configuring yargs through package.json is deprecated and will be removed in the next major release,
success open and validate gatsby-configs - 0.565s
success load plugins - 0.325s
success onPreInit - 0.003s
success initialize cache - 0.008s
success copy gatsby files - 0.036s
success onPreBootstrap - 0.030s

 ERROR #11321  PLUGIN

"gatsby-plugin-mdx" threw an error while running the onCreateNode lifecycle:

unknown: Expected corresponding JSX closing tag for <img> (9:102)

Followed by a bunch of these errors
 ERROR #98123  WEBPACK

Generating development JavaScript bundle failed

Can't resolve 'theme-ui' in '/Users/michael/Projects/coolfire/coolfire/node_modules/gatsby-theme-docz/src'

File: ../node_modules/gatsby-theme-docz/src/index.js

Expected behavior
It should spin up the local docz environment
Environment

docz version: 2.0.0-rc.75
OS: OSX 10.15.1
Node/npm version: 12.13.0/6.12.0
Yarn version: 1.19.1

Not sure who to ping here, @rakannimer can you point me in the right direction or give me some help. Would love to use this in my project.

Finally got it to work. However, it was still attempting to parse my README.md file despite setting files to **/*.mdx and src to a folder that doesn't contain that file.
Also, found that I had to have an index.ts file inside my component folder.

Sorry I couldn't help because I couldn't recreate your setup due to a bad connection, it would stop midway.
If you update to next tag, your readme will be ignored by using src
yarn add docz@next

You can also use the ignore array to tell docz not to include your readme if you don't want to update but it will still attempt to parse it.


problem with std::shared_ptr's reference count

When I copy a shared_ptr into lua and then setting the value to nil, the instance in lua is not destructed as expected. Any suggestions how to fix that other then using raw-ptrs for lua refs instead?
#include <sol.hpp>
#include <iostream>
#include <memory>

struct TestMe
{
    TestMe() {}
    ~TestMe()
    {
        std::cout << "DESTRUCTED" << std::endl;
    }
};

int main()
{
    auto test = std::make_shared<TestMe>();

    sol::state lua;

    lua["test"] = test;
    std::cout << test.use_count() << std::endl; //prints 2 since we just copied the ptr into lua
    lua["test"] = sol::nil;
    std::cout << test.use_count() << std::endl; //still prints 2! why?

    return 0;
}

Because Lua runs on a Garbage Collection system and that might not trigger the "DESTRUCTED" until Lua deems that it needs to throw away that memory.
Note that when the Lua State is destroyed, that destructor runs.
 Even then, calling lua_gc(lua, LUA_GCCOLLECT, 0); does not mean that "test" will be cleaned up.

Well, that completely ruins the point of shared_ptrs, since my objects stay alive for a random amount of time when I actually expect the reference counter to be 0.
Since destructing the lua state indeed works, I will test performance when creating a local state each time a want to run a set of scripts. Do you generally suggest such an approach?

It doesn't make any sense at all, because once Lua takes a dependency on the memory it will delete it whenever it feels like. That's exactly how Garbage Collection works: see every garbage collected language ever invented for all time. The whole point of having a GC in a language is that you give up some control for the overall benefit of not explicitly managing your memory and perhaps some memory locality and up-front allocation benefits.
It would be nice if Lua's garbage collector wasn't an old dog from ages long ago, but it is. Both LuaJIT and the most recent iteration of Lua have interested in implementing a new GC that would behave better, but even then the language has no guarantee when your object would be destroyed.
The reason you'd use a shared_ptr with Lua is if you throw something into the Lua system, but don't know if the C++ version or the Lua version will die first. If you don't have a need for that, use a std::unique_ptr, std::move it into Lua, and then let Lua kill the memory without holding onto it in C++. Make sure nothing depends on the thing being deleted, and so whenever Lua destroys it things will be fine.
That's really all the advice I can give you. As I said earlier, you're dealing with GC in Lua, not C++'s RAII. You have no memory guarantees with the Lua Language.

I totally accept the GC "drawback" from lua, thanks anyway for clarifying the point.
Funny thing is, the solution for me is as simple as this:
    auto test = std::make_shared<TestMe>();

    sol::state lua;

    lua["test"] = test;
    std::cout << test.use_count() << std::endl; //prints 2 since we just copied the ptr into lua
    std::shared_ptr<TestMe>& testBack = lua["test"];
    testBack.reset();
    lua["test"] = sol::nil;
    std::cout << test.use_count() << std::endl; //hurraayyy

As long as I forbid creating shared_ptr instance inside lua-code, that solves my problem. I reset the ptrs manually and dont care when GC destroys the empty wrappers left back.
Only problem left atm is about weak_ptrs. I have a weak_ptr instance registered in lua and want to use it. Since converting it to a local shared_ptr variable would again trigger the GC problem, I currently tend to call weak:lock() simply every time I use the weak_ptr. Like:
namespace sol
{
    template <typename T>
    struct unique_usertype_traits<std::weak_ptr<T>>
    {
        typedef T type;
        typedef std::weak_ptr<T> actual_type;
        static const bool value = true;

        static bool is_null(const actual_type& value)
        {
            return value.expired();
        }

        static type* get (const actual_type& p)
        {
            return p.lock().get();
        }
    };
}

Not really aesthetic, but it works. One last question: Any thoughts about that?

That looks a tad dangerous. p.lock() creates a new std::shared_ptr, and then you .get() the value out of it. Aside from holding onto a pointer value of a temporary shared pointer that's destructed by the time that get function has its value returned to the system (dangerous), can't really fault the code.

I tried adding a function like this:
	void SOL_RESET_SHAREDPTR(shared_ptr<Model>& sptr)
	{
		sptr.reset();
	}
	lua.set_function("Delete",SOL_RESET_SHAREDPTR);

And then I tried it in Lua:
local model = CreateBox() --returns a shared_ptr<Model>
Delete(model)

The result was a shared_ptr in lua that had an invalid pointer and didn't know it. I'm not sure how, but it seems very dangerous.

@JoshKlint when you're allowing people to explicitly "delete" things you should also be prepared to handle cases where they might try to use something deleted. One way to avoid this issue is to follow standard lua semantics and handle deletion as part of the Garbage Collection process, where things are destroyed when they go out of scope and GC occurs. This of course may not fit with the programming model you're trying to create, in which case probably the best way to ensure someone can't break your program by trying to do things on deleted objects is to perform additional checks internally (inside your bound methods, etc.) to make sure your shared pointer is still holding a valid pointer.

Yeah, I don't think it's a good idea. I'm okay with something like this:
local model = CreateBox()
model:Hide()
model = nil -- It will happen when it happens

Or this:
local model = CreateBox()
model = nil
collectgarbage()

It really does seem like this should work:
void SOL_RESET_SHAREDPTR(shared_ptr<Entity>& sptr)
{
	sptr = nullptr;
}

The user is not deleting a Lua object, they are changing the state of the shared_ptr that Lua is passing around.

@JoshKlint So this is a problem of how memory is represented with "unique_usertype"s: http://sol2.readthedocs.io/en/latest/api/unique_usertype_traits.html
This means that the front-side of the unique_usertype (the pointer) isn't updated. A little bit unfortunate. There is a way to fix it, but I never provided the function to do it. I probably should.... but I'm heading off to class.

@JoshKlint Here's a potential fix, pushed to latest.
I can guarantee that this is probably a bad idea and will violate user expectations, but go crazy: https://github.com/ThePhD/sol2/blob/develop/examples/shared_ptr_modify_in_place.cpp

Okay, this code will print false and then cause an exception:
if window:KeyHit(KEY_SPACE) then
	Reset(model)
	print(model==nil) --prints false
	model:Hide()
end

Proper usage would be like this:
if window:KeyHit(KEY_SPACE) then
	Reset(model)
	model = nil
end

For most types of objects it is perfectly fine to let them hang around a while before the garbage collector discards them. However, visible objects are an issue. At this point this is probably the best approach:
if window:KeyHit(KEY_SPACE) then
	model:Hide()
	model = nil
end

However this is operating on the assumption that we know this is the only place the object is being used. Maybe some other part of the code is keeping the object alive and we don't actually want it hidden. We don't know. So in that case, maybe this is a bit better:
if window:KeyHit(KEY_SPACE) then
	model:Hide()
	collectgarbage()
end

This is the solution we really want, but I don't know if it is possible:
if window:KeyHit(KEY_SPACE) then
	Reset(model)
	print(model==nil) --prints true
end

That second to last example should be like this. I can’t find an edit button on my phone:
‘’’
model = nil
collectgarbage()
‘’’

Lua does not support in-place type changing. This means that out parameters and function calls cannot fundamentally change the type of the variable that calls it / is called with it.
There's just nothing you can do. This is, of course, the problem with having a reference-based language that does not let the user override operator= for the current type, but only its children.

Okay, this design is satisfactory. Thanks again for creating this library. My users are very excited about these new capabilities.
https://www.leadwerks.com/community/blogs/entry/2147-more-amazing-things-you-can-do-with-lua-in-leadwerks-5/

@JoshKlint That's great! Would you mind if I put that blog post in the Mentions page on the sol2 documentation?

See ya in 1-2 years 😉


HTTP Runtime

This change allows the workflow engine to support tasks directly referencing urls in the tasks. For the inputs these tasks follow the same conventions as the internal http function:
myTask:
  run: http://ifconfig.co
  inputs:
    method: POST
    body: "hello world"

To ensure consistency of behavior both approaches share the same implementation. For example, the above example using the HTTP runtime is equivalent to:
myTask:
  run: http
  inputs:
    url: http://ifconfig.co
    method: POST
    body: "hello world"

Part of this change also loosens the validation of the function reference to be equal to that of an URL (before it was a subset). This simplifies the model, and allows us to rely on the existing parsing and tooling around URLs.
The HTTP runtime can be enabled with the --http argument, which has been added as a default

Is there a more explicit variant possible, where the yaml explicitly says "http-request" instead "run"?

Yes, I don't really have a preferred approach, which is why I initially wanted to support both. I am fine with only supporting the second approach from a users perspective. 👍


Disappearing val/var modifiers in class parameters

Reposted from https://github.com/scalameta/scalameta/issues/555
class Identity extends scala.annotation.StaticAnnotation {
  inline def apply(defn: Any): Any = meta {  defn }
}

@Identity
class Test(val value:Int) extends AnyVal

Doesn't work, because the val modifier is lost and then the AnyVal infrastructure complains about that.

@Keshi thanks a lot for reporting!
This seems to be an issue in the infrastructure that converts scala.reflect ASTs into scala.meta ASTs (something that we call "the converter").
Here's the relevant code excerpt from https://github.com/scalameta/paradise/blob/1dd67faaf312af15ff8a6ecde963b7a4649108d0/plugin/src/main/scala/org/scalameta/paradise/converters/LogicalTrees.scala#L1130-L1140:
object PrimaryCtorDef {
  def apply(tree: g.ClassDef): l.PrimaryCtorDef = {
    val CtorDef(mods, name, paramss, stats) = tree.primaryCtor
    val lparamss = paramss match {
      case List(List()) if !tree.mods.hasFlag(CASE) => Nil
      case paramss                                  => paramss
    }
    require(stats.isEmpty)
    PrimaryCtorDef(mods, name, lparamss)
  }
}

As you can see, here scala.meta extracts the parameters of the constructor (paramss) encoded in scala.reflect parlance and then immediately uses them to build the scala.meta tree corresponding to the primary constructor.
Unfortunately, scala.reflect doesn't have the notion for val/var modifiers on parameters. If the parser finds such a modifier, it drops it and desugars such a parameter into a combination of a constructor parameters and corresponding getters/setters. As a result, paramss extracted from the scala.reflect constructor don't know whether they are val/var.
A possible fix would be to change the logic of PrimaryCtorDef.apply to:

Check the definition of the input tree: ClassDef for whether it has associated getters/setters.
Update paramss to include val/var modifiers as appropriate.

I won't have time for this in the coming week or even more, but I would be glad to guide you through contributing a fix. Would you be interested?

I just submitted #138 to fix this issue.


etcdserver: remove 2.0 StatusNotFound version check

lgtm

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@8fa4b8d). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #7771   +/-   ##
=========================================
  Coverage          ?   75.58%
=========================================
  Files             ?      331
  Lines             ?    26085
  Branches          ?        0
=========================================
  Hits              ?    19716
  Misses            ?     4929
  Partials          ?     1440

Impacted Files
Coverage Δ

etcdserver/cluster_util.go
76.64% <ø> (ø)

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 8fa4b8d...3d8e2e1. Read the comment docs.


Timezone-aware DateTime64 columns now returned missing the timezone info

Describe the bug
Timezone-aware columns in Clickhouse like (DateTime64(6, 'America/Chicago')) used to be returned by query_df in correspondingly timezone-aware DataFrame columns of type pandas.DatetimeTZDtype(unit='ns', tz='America/Chicago') until (at least) version 0.5.7 of clickhouse-connect. In the latest version 0.5.12 such columns are returned as timezone-unaware numpy.datetime64 columns.
Steps to reproduce

Create a table with a (DateTime64(6, 'America/Chicago')) column; insert some data
Query the table using query_df
The dtype of the column in the returned DataFrame will be pandas.DatetimeTZDtype(unit='ns', tz='America/Chicago') if using clickhouse-connect version 0.5.7 (i.e., timezone-aware), but numpy.datetime64 if using clickhouse-connect version 0.5.12 (i.e., timezone-unaware).

Expected behaviour
Returned colunm dtype is pandas.DatetimeTZDtype(unit='ns', tz='America/Chicago')

That is related to https://github.com/ClickHouse/clickhouse-connect/issues/120.
For various obscure historical reasons ClickHouse does return the timezone information for a DateTime64 column, but doesn't return that information for a DateTime column (in the particular case of HTTP using Native format) so clickhouse-connect was not setting timezone for any DateTime column (after the internal switch from RowBinary to Native format).  There's a workaround where the client can specific the timezone as a keyword argument (query_tz/column_tzs), but even that doesn't work for pandas currently.
I have a fix for the DateTime64 issue, which will also enable the query_tz/column_tzs workaround.  That fix will probably be released early next week.  Also, in today's release of ClickHouse, there's also a fix for the problem of not returning timezone information for DateTime columns.  However, that will only work with the most recent ClickHouse version 23.2.x and also requires the next clickhouse-connect release to handle the low level change.  So eventually, with the latest ClickHouse server and clickhouse-connect version, the workaround won't be necessary.
  Oh well.)

In my experience, all timestamps are a pain to work with, but timezone-unaware DateTimes in Clickhouse are even harder to deal with than timezone-aware ones, because, empirically, they are assumed to be in the system timezone and then converted to UTC before being inserted in Clickhouse, which is extremely confusing. Writing a 2023/02/23 22:30 timezone-unaware timestamp to a DateTime column via either a direct call to clickhouse-connect's insert_df or clickhouse-client through a flat file ends up writing a timezone-unaware 2023/02/23 16:30 timestamp to the Clickhouse table (probably via the same code path, maybe on the server side) because my system timezone is set to America/Chicago, which is UTC+6. When such timestamps are read back, they need to be localized to UTC, converted to the system default timezone, and then localized to None (erasing the timezone info). That's a hassle.
The way DateTime64(timezone) was handled by clickhouse-connect version 0.5.7 was the most user-friendly, because it needed absolutely no adjustments on either writing or reading. Ideally, DateTime(timezone) would work the same, and maybe even timezone-unaware DateTime and DateTime64 would not need any extra conversion work. At the very least, behavior should be deterministic so users can at least code up the right type of timestamp massaging.
As always, your effort for dealing with these issues is much appreciated.

Interesting, I suspect the string conversions to a pandas Timestamp/clickhouse-client flat-file to DateTime which assume the system timezone is probably the culprit in both cases.  I don't know enough about such conversions to know if there is a way to configure them to assume a UTC timestamp from the bare string, but the whole situation is definitely fragile.
In any case the 0.5.7 behavior should work again in the next release -- presumably 0.5.13 -- for DateTime64.  The regression was a side effect of using numpy arrays as the basis for all pandas series (instead of -- in the case of DateTime64 -- a list of Python datetime.datetime objects which were timezone aware).   Unfortunately Python timezone handling is very inefficient, so the fix will come at a performance cost for timezone aware columns, but it should work as expected.


error execution in web environment

First thanks for your work JEPIQUEAU, I am following the documentation for trying to run the plugin in the web development environment and then build with capacitor to android but I have this error:
Error: Uncaught (in promise): Not implemented
after invoking the open method.
The plugins do not work on the web?

@jsoret First thanks for using the plugin. You right, there is no implementation for web. Browsers do not support sqlite storage, this is the reason why you get the message Not Implemented.


Improves few tests and an assert method

Description:

Related issue(s):
Fixes #
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Codecov Report
Patch coverage: 66.66% and project coverage change: +0.01% :tada:

Comparison is base (916c12e) 78.24% compared to head (44e1142) 78.26%.
Report is 6 commits behind head on main.

:exclamation: Current head 44e1142 differs from pull request most recent head d0c57fd. Consider uploading reports for the commit d0c57fd to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1572      +/-   ##
==========================================
+ Coverage   78.24%   78.26%   +0.01%
==========================================
  Files          32       32
  Lines        2625     2627       +2
  Branches      544      545       +1
==========================================
+ Hits         2054     2056       +2
  Misses        405      405
  Partials      166      166

Files Changed
Coverage Δ

packages/relay/src/lib/clients/mirrorNodeClient.ts
89.54% <66.66%> (+0.05%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


No more \newcommand in StackEdit 5

In StackEdit 4 I just began each of my documents with a preamble that contained a bunch of custom commands.  e.g.
$$
\newcommand{\pderiv}[2]{\frac{\partial #1}{\partial #2}}
\newcommand{\argmax}[1]{\underset{#1}{\operatorname{argmax}}}
\newcommand{\argmin}[1]{\underset{#1}{\operatorname{argmin}}}
\newcommand{\switch}[3]{\begin{cases} #2 & \text{if } {#1} \\ #3 &\text{otherwise}\end{cases}}
$$

I see that using \newcommand is no longer allowed in StackEdit 5 (guess because Katex is now used instead of MathJax?).
This is kind of a deal-breaker for me.  Is there any workaround other than reverting to StackEdit 4?  Maybe there's a way to make it use MathJax?

Yes the v5 uses katex. We have to wait for this ticket to be closed: https://github.com/Khan/KaTeX/issues/37

KaTeX is really behind MathJaX.
It hurts Students using StackEdit.
Any chance you give us the option to use MathJaX as it used to be?
Thank You.

I'm working on my project Moeditor, a local markdown editor app. Maybe I'll use StackEdit 5's core and add MathJax support.

Note that \newcommand has been implemented in the latest KaTeX: https://github.com/Khan/KaTeX/pull/1382

\newcommand still not working on stackedit5?

Seems not yet, I still get:
KaTeX parse error: Expected 'EOF', got '\newcommand' at position 1: \̲n̲e̲w̲c̲o̲m̲m̲a̲n̲d̲{\pderiv}[2]{\f…

Upgraded to katex v0.10.0-rc.1.

Thanks, now \newcommand works within one "$$" but still not globally...

I still find this to be an issue:

StackEdit used to have perfect compatibility with StackExchange network for Math.
Yet since the move to KaTeX in StackEdit 5.x this doesn't hold anymore.
I really wish for a MathJaX mode with proper scientific writing as we had before in StackEdit.
MathJaX can work with ID / Labels just like KaTeX.

I have been using hackmd for a while but they dont support working offline, so now I am trying stackedit. But without having \newcommand available, I will not take it up more seriously. Any other recommendations? Is there a system that supports offline work and \newcommand/full mathjax?

@alexhkurz , I use VS Code + MarkDown Preview Enhanced.
It works perfectly!
If you can skip the live preview, I think the best is Sublime Text + MarkDown Preview (By @facelessuser).

Oh well chump idgafa so I hope you got aids gov and herpes.

On Sun, Oct 21, 2018, 1:26 AM alexhkurz<EMAIL_ADDRESS>wrote:

thanks ... I am just trying VS Code + MarkDown Preview Enhanced ... looks
good so far ...

On 20 Oct 2018, at 22:46, Royi<EMAIL_ADDRESS>wrote:
@alexhkurz , I use VS Code + MarkDown Preview Enhanced.
It works perfectly!
If you can skip the live preview, I think the best is Sublime Text +
MarkDown Preview (By @facelessuser).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/benweet/stackedit/issues/1216#issuecomment-431642556,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AnO0AA1KPR1d5zKzfEvj2oQkVJSVNvMwks5unBOigaJpZM4RxEqx
.


refactor: refactor fuse sidecar mutator with pod-level info

Ⅰ. Describe what this PR does
The PR refactors fuse sidecar mutator with pod-level info. It replaces injector.injectObject() func with mutator.MutateWithRuntimeInfo() func which mutates pod according to different serverless platforms. Also, this PR adds a PostMutate() func in the Mutator interface to allow some global mutations on the pod.
Ⅱ. Does this pull request fix one issue?

NONE
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

/test fluid-e2e


Device query

@willrogers, some initial feedback on what you think of the backend work would be helpful. Will add new tests once I know this is the right direction.

Yes, this looks more like what I expected.

@willrogers this should be the backend for devices done now hopefully

This looks fine to me. Would you like to merge, or continue working on this branch?

Merging would be good, I'm conscious of the refactor you want to merge in so don't want this branch to get too outdated.


fixed#226 added validation  to subscribe textfield

Title and Issue number
Title :  BUG validation for Subscribe button #226
Issue No. : #226
Code Stack :
Close #226

Video/Screenshots (mandatory)

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have gone through the  contributing.md file before contributing

Additional context (Mandatory )
Are you contributing under any Open-source programme?
jwoc

pls check this PR


initial tests for Matrix3. The applyToBufferAttribute method test wil…

…l be done later, once we get BufferAttribute working. The setUvTransform method test isn't working, but we don't need it for the initial demo.

I wonder why CI is not running on this PR. I'm gonna email GitHub support before merging this one.

GitHub support emailed back and recommended Closing and re-opening to see if it would re-trigger the build, and indeed it did.


sciter-x-api.h Has changed

LPVOID reserved1;
LPVOID reserved2;
LPVOID reserved3;
LPVOID reserved4;
UINT64 SCFN(SciterAtomValue)(const char* name); //
BOOL   SCFN(SciterAtomNameCB)(UINT64 atomv, LPCSTR_RECEIVER* rcv, LPVOID rcv_param);
BOOL   SCFN(SciterSetGlobalAsset)(som_asset_t* pass);
The API header file has changed

Thanks! I will take a look at it this weak

Version 3.0.0 is up with the update!


chore: Set jest env as node to avoid jsdom overhead

Sets jest config in package.json. Reference docs - https://facebook.github.io/jest/docs/en/configuration.html#testenvironment-string

Thanks! I didn't know that!

Me neither.. Got it from here - https://egghead.io/lessons/javascript-test-javascript-with-jest


Calibrator ng

This implements all the additional functionality needed for the calibrator.
The data file to run testbench calibrator_tb.m can be found here

The bether file can be found here