text:
Suggest cleanup of geometry handling in the CPU version

As I mentioned in my comment to #52, the way the CLI version of our code handles the geometry parameters (params['gridA'], ... params['gridN'], lvec, nDim etc.) could use some cleanup. For starters, I propose we discuss this issue:

What do we expect to be the role of gridA, gridB, gridC, and gridN parameters in the code? Do we want them to be just an optional input (in case the geometry is not specified by other means, in particular in a *.xsf or other input file)? In such a case, they can be safely forgotten (I do not mean literally deleted, just ignored) after the initialization stage. The actual lattice vectors and grid size should be consistently carried in variables like lvec and nDim throughout the actual computation. Alternatively, do we want parms['gridA'], ... params'['gridN'] to serve as a global variable? Then, we should consistently work with those. In the most extreme version of this choice, we would not even need to introduce lvec and nDim variables at all. I can somehow understand that a compromise might be desirable: Perhaps we want some functions to be also usable as stand-alone entities, without being called from the main scripts. A moderately experienced user might want to do something in an interactive Python session. The loadGeometry function is one of those we may want to be able to call this way. Than, it makes sense for such a function to take lvec, 'nDim` etc. as arguments and store them as its local variables. On the other hand, some other functions may be intended as mere subprograms of the main executable scripts and need access to global variables, since passing everything they need through arguments to them would be inefficient and would generate too long argument lists. I suspect this compromise was what @ProkopHapala had in mind when originally writing the code. Prokop, is that so? I am actually in favor of the compromise solution, given that we decide very carefully which functions should be the independent entities, taking geometry parameters as their arguments and perhaps returning them as their values, which functions should in contrast access the global variables, and why the chosen option is needed in every case. Because if we are not clear about this, we inevitably end up with the mess we currently have.
As a second point, I would like to make sure that the code reads the origin of the unit cell from the *.xsf and *.cube files every time, stores it and handles accordingly. That is, the code should not rely on the origin being zero. We might even introduce an optional parameter params['gridOrigin'] to params.ini, which would be used with *.xyz files. That should solve the problem with negative coordinates of atoms in non-periodic systems, which is currently effectively forbidden.

I failed to reproduce what I thought was the most severe issue that motivated this proposal for a thorough cleanup with regards to how the geometry is being handled. I was under the impression that sometimes, the grid/lattice parameters read from params.ini are taken into account even though they should have been overwritten with a *.cube input. I do not know what happened then, probably some error in one of my *.cube files that disappeared after I had recalculated everything, but now it looks as though the problem was not with the ppafm code. Anyway, there are still several open issues related to geometry in one way or another, like the recent #201, #200, #199, the older #190 and #6, or even #52, though I have created a pull request associated with the last one recently. I would still prefer forcing some consistent logic onto the geometry handling along with solving those issues rather then just close those with some ad hoc patches that would somehow work until they'd bite us to our backs with any new modification of the code.

I began reviewing the code and now it seems to me that what I will advocate with respect to the geometry will need not be any big revolution after all. I have looked into core.py and I think I gather the logic followed there. The primary source of information on lattice vectors is typically a argument called cell, an analogy of lvec from HighLevel.py, coommon.py or io.py, but the global parameters , params['gridA'], params['gridB'], params['gridC'] may be used as a backup source if cell is undefined. I believe this is a good way to do things, so I will try to keep this logic consistently.
I have a question about the function setFF, defined here: https://github.com/Probe-Particle/ppafm/blob/2344a7b01000bbf8ce3d2ddbf92abf3b9fe917c9/ppafm/core.py#L70
Do we even need it? I mean, it seems to be used only in some obscure examples in examples/_bak/. Do we want to have these as a part of the ppafm package? If not, I suggest we remove those examples along with the function setFF. Otherwise, if we want to keep it, I suggest the following small cleanup: setFF seems to reach for the global grid parameters twice if cell is None; first directly in its body and second time (but this never happens because by then cell has been already defined by the first case) through setFF_shape which in turn calls setGridCell. I would remove the test of cell is None and the subsequent assignment of gridA, gridB, gridC from setFF , relying on this being done in setGridCell.
Moreover, if we use gridA, gridB, and gridC as the default for the lattice vectors in core.py, I believe we should also use gridN as the default for the grid size there (in particular, probably in the setGridN function). This enhancement should in fact not change the behavior of our code at this moment, because the flow of the code is now such that the core.py functions are always called for some pre-established FF array and learn the grid from the shape of this array. That is fine and should remain that way, but I still think the setGridN should check the n argument for being None and use gridN as the fallback in such a case, just to make the code more robust.

Just to clarify how I expect the job related to this issue would be done: I will do it, of course, but only after hearing the opinion of others.

Another candidate for deletion: wrapAtomsCell in common.py. Seems to be used nowhere. The function it implements, as far as I can tell, is this: shift positions of atoms by [da + 10, db + 10], then fold them back to the first unit cell. Might be useful perhaps, but at the very least, if we are going to keep it and use it, the artificial and mysterious shift by 10 should be removed.

@mondracek

I suspect this compromise was what @ProkopHapala had in mind when originally writing the code.

yes, it is true I was aiming for such compromise. But it is also true some structures in the code are just for historical reasons (to minimize effor of rewritining parts of code which are already there)

In general I think it is reasonable to consider lvec and nDim to be main storage of information about the lattice. gridA, gridB, gridC are mostly just for user input in input.ini (so that each line in the input-file has some name)
I think some trubles with molecular geometry and lattice whould be reduced if we define class which pack them togheter (including the origin of the lattice). I know people were suggesting to use ASE but to me it seems overkill (introduce dependnece on huge 3rd party package into core of ppafm - that I don't like). I would rather make something like class AtomicSystem which I have in my other project (it encapsutlates reading and loading, keeps the lattice vectros, originn, atomic types, positions, parameters, etc.). Than we can pass instances of that class into fuctions (rather than passing arrays indepenendtly), which simplyfy the interface.

but I'm not sure if to do it now, since it is quite large reoganization of the project

I would still prefer forcing some consistent logic onto the geometry handling along with solving those issues rather then just close those with some ad hoc patches that would somehow work until they'd bite us to our backs with any new modification of the code.

I'm very much pro. If you have ideas pleas go ahead with proposing them. I'm very open to it. I'm just not enough systematic myself, and also currently it is not my priority.
ad setFF
what you meanit is not used? OK, maybe setFF() is not used, but setFF_shape() and setFF_pointer() are used a lot. Without them you cannot share forcefield between python and C++ part.
So yes, this is also perhaps more historical. Firts I wrote setFF(), then I realized that often I need more fine-controle (to set shape and data of the grid forcefield independnetly). So I factored out  setFF_shape() and setFF_pointer(). So yes, perhaps now setFF() is almost not used.
ad wrapAtomsCell - I don't really remember what I used it for. Perhaps I used it just once for some debugging.

@ProkopHapala, thanks for the reply. As for the setFF() function, yeah, I mean setFF_shape() and setFF_Fpointer() or setFF_Epointer() are called directly whenever one might want to call setFF(). So I suggest we either delete the definition of setFF() or we actually use it where appropriate. Perhaps we can unite setFF() and prepareArrays() into one function and use that one. Now, as I understand it, both functions are doing similar jobs but

prepareArrays() does not call setFF_shape(). We always call setFF_shape() shortly after prepareArrays(), however
setFF() calls setFF_shape() but, in contrast to prepareArrays(), it cannot create a new array if the corresponding aray argument is None

Now I see that the C functions setGridN and setGridCell are defined in both ppafm/cpp/GridUtils.cpp and ppafm/cpp/ProbeParticle.cpp. The definitions are identical so the duplicity should not cause any problem until we happen to change one of them, but still, it does not feel correct.

Now I see that the C functions setGridN and setGridCell are defined in both ppafm/cpp/GridUtils.cpp and ppafm/cpp/ProbeParticle.cpp. The definitions are identical so the duplicity should not cause any problem until we happen to change one of them, but still, it does not feel correct.

I agree that it is not nice from the point of code structure (modularity etc.). But the point is that GridUtils and ProbeParticle both compiles into independnet binary (.so) and they does not depend on each other.
But yes, it would makes sense to factor out these duplicite things into singe header file (.h). But I'm not sure how it works if the function is in extern C{} (if it is not problem to have extern { in header file ?)

prepareArrays() does not call setFF_shape(). We always call setFF_shape() shortly after prepareArrays(), however
setFF() calls setFF_shape() but, in contrast to prepareArrays(), it cannot create a new array if the corresponding aray argument is None

OK, to be honest I don't remember exactly the code structure and the rational nor the historical path which lead to this. If you find it nicer that way, feel free to change it as you say

Good. Concerning the duplicity of setGridN() and setGridCell() function, I'd rather leave it as it is for now because I am also not sure how exactly the C linking works and I might actually break it by trying to repair it. I guess moving the duplicate into a header should work in principle, although the header files might not be exactly intended for such purpose, because including a header file into a *.cpp file through #include should be (as long as I understand it) done by the preprocessor essentially by pasting the plain text of the *.h file into the *cpp file before the compilation. But I am not quite sure. If anyone of you other guys knows how to handle this in C properly, you are welcome to propose a solution.
Otherwise, I see now that the cleanup I wanted to make will not require as radical changes of the code structure as I thought when I started this issue. So I will rather pick up more specific tasks concerning the handling of geometry (and force field grids) and I will do the cleaning along the way.
One of those specific issues I am planing to address would be that we introduce the proper handling of the origin as recorded in *.xsf and *.cube files. See the second bulleted point in my first comment in this thread. Do you agree that this should be done? Other such issues are those referenced in my second comment here (#6, #190, #199, #200, #52) .

I'm also very much in support for packing things into a class object. And I already did something in this direction in the OCL API with the DataGrid (except without the atoms), It could be nice to somehow interface this with the CPU part, maybe make the DataGrid a subclass of the whatever class we create for the core code

Yes, I like your DataGrid class. Maybe we should discuss more what ideas you have about class hierarchy or relations? You mention CPU vs GPU. But I would perhpas first speak about geometry (i.e. atomc coordinates and types) vs grid (3d array) vs lattice vectors.

One option is to make one dynamic class, which have optional fields (e.g. initialized to None). e.g. it may or may not have data grid, it may or may not have atoms, or lattice vectors.
Another option would be to make hierarchy. E.g. starting from Atoms class, then add lattice vectors AtomsPBC and then ad grid (array) ... or in other order?
Another option is to make 2-3 independnet classes e.g. (i) Atoms which strores atomic positions and types (ii) Grid which stores lattice vectors and optional data array. And them pack them together in e.g. AtomGrid class

Because python in very dynamic unlike C++, It woudl maybe prefer (1) i.e. to have optional dynamic fields. The disadvantage is that it would require to put everywhere checks if some field is initialized, like if( lvec is None  ):

Also, I already used ASE as an optional dependency in the GUI for the geometry viewer.

Don't understand me wrong. I'm very much pro integration with ASE as optional dependency. I also use ASE and I like it. But I don't like the idea to depend on it in such core functionality as loading and manegind atomic coordinates (i.e. not being able to run ppafm at all without ASE)

One option is to make one dynamic class, which have optional fields (e.g. initialized to None). e.g. it may or may not have data grid, it may or may not have atoms, or lattice vectors.
Another option would be to make hierarchy. E.g. starting from Atoms class, then add lattice vectors AtomsPBC and then ad grid (array) ... or in other order?
Another option is to make 2-3 independnet classes e.g. (i) Atoms which strores atomic positions and types (ii) Grid which stores lattice vectors and optional data array. And them pack them together in e.g. AtomGrid class

I would avoid deep class hierarchies (2). They become very rigid and difficult to change when new needs arise, and it's often not clear at which level of the hierarchy some piece of data should exist.
So I would opt for composition instead (1, 3). I see 1 and 3 being structurally the same. E.g. either we store the lvec and grid as np.arrays or some custom classes of our own, but in any case they exist as properties of the storing class, and that structure can be changed internally flexibly.

I have to say, that one thing I hate about python is that due to dynamic initialization of class properties, it is often not clear what properties the class is supposed to have when reading the code (at least comparing to C++). This was actually main reason why I considered classes in python poinless for quite long time. Do you know some good practicies how to make the declaration of class properties in python more explicit?

One way to do this is to make all of the internal variables private (prefix with underscore _) and then make an interface by using the @property decorator for class methods. For example, in the DataGrid I store the host numpy array like this: https://github.com/Probe-Particle/ppafm/blob/4e04d47cefac340ab734a2ef4000cc901793c5b0/ppafm/ocl/field.py#L118
but it can also sometimes be None because it exists on the GPU instead. And then I create a property method that returns the array after checking that it's fine: https://github.com/Probe-Particle/ppafm/blob/4e04d47cefac340ab734a2ef4000cc901793c5b0/ppafm/ocl/field.py#L152-L158
The @property decorator makes it so that you can access the method as if it's just an attribute, e.g.
array = datagrid_instance.array

With the doc string in the method, it also makes for nice documentation, so the API is clear: https://ppafm.readthedocs.io/en/latest/ppafm.ocl.html#ppafm.ocl.field.DataGrid.array

I'm not sure which is best approach. Because python in very dynamic unlike C++, It woudl maybe slightly prefer (1) i.e. to have optional dynamic fields. The disadvantage is that it would require to put everywhere checks if some field is initialized, like if( lvec is None  ):

We can probably make this simpler for ourselves by insisting that some of the fields always exist. The lvec we can for example read from the default parameters if it's not set, as Martin suggested above.
I think this consideration also encourages splitting the functionality into multiple classes (option 3.), because then if you only need the grid, for example, then you can just use the Grid class instead of the AtomGrid.

I noticed that the use of classes for storing geometry has been already suggested by @ProkopHapala before, as issue #97. Perhaps we can close that issue noting that the discussion has been transferred here.
I have been recently trying to enable reading data from XSF files created by the FHI-AIMS code. There were some issues specific to FHI-AIMS that prevented loading them with the loadXSFGeom and loadXSF functions from ppafm/io.py as these function stand now. I will explain more when I start a dedicated issue about that. What I want to say for now: Working with the XSF files, I noticed that the vectors that define the grid can be in general something completely different from the lattice vectors that define the periodicity. In our code, we essentially work with the grid vectors and when we happen to need the lattice vectors, we pretend they are the same. I am not saying we need to change this approach right now, but we should keep in mind that we might need to differentiate between the grid vectors and lattice vectors in the future. So when rewriting the code, introducing new classes for the geometry etc., we should do it in a way that at least does not make future splitting of lattice vectors from grid vectors more difficult than necessary.

we pretend they are the same. I am not saying we need to change this approach right now, but we should keep in mind that we might need to differentiate between the grid vectors and lattice vectors in the future.

Not sure I understand.

Do you mean that there are situations (systems) where it would be usefull to distinguies the two ?
Or that in the code there is no checking mechanism which makes sure grid vectros and lattice vectros are the same (while they should be) ?

@ProkopHapala: Both, sort of.

There may be cases, admittedly not particularly common, in which the distinction might be useful. For example, @NikoOinen mentioned to me when reviewing my PR #216 that the user may be interested in a relatively small scanning region that does not cover the whole system. Then, it is enough if the grid includes just the scanning region plus some padding. This will more likely happen for large non-periodic systems but such scenario is not entirely excluded for periodic systems either. If atom-centered potentials like LJ are going to be used to calculate the force field and if the requested scanning region is situated at or near the periodic cell boundary, the lattice vectors of the true periodicity cannot be ignored even though the grid size should be smaller than the unit cell.
More often, the grid should cover exactly one periodic unit cell. For example, we rely on this when the scanning region crosses the unit cell boundary and the tip position rolls from one unit cell to another. But we do not check whether the grid axes defined in XSF files really agree with the lattice vectors in the same file, even if we expect that they do.
In files like OutFz.xsf, the grid axis in fact should not be the same as the lattice vectors. The grid axes determine the scanning region there and that is usually different from the system's periodic unit cell. At this moment, we simply do not write the lattice vectors into OutFz.xsf at all. That does not matter as long as we consider these OutF?.xsf files just a temporary storage of intermediate data produced by ppafm-relaxed-scan before they are passed to ppafm-plot-results. The ppafm-plot-results script does not need the information on lattice vectors. However, I do not like this approach in which the files like Outfz.xsf are seen as something internal to the ppafm code only. Why bother splitting the code into several scripts unless the output from each of the script can stand on its own? Once the user wishes to view and analyse this force fields separately, it would be desirable that the XSF files include information on the position of atoms and on the lattice vectors. We have in fact done the same for the FF*.xsf files already.

By now, I have started working on the problem of properly defining the grid origin, as needed to solve #223. On that occasion, I noticed there are parameters called FFgrid0, FFgridA, FFgridB, and FFgridC, the purpose of which is exactly to define grid geometry different from periodic lattice vectors, but only for the OCL version (see the discussion under #139). I do not really understand how the OCL version works, but can we perhaps adapt the solution used there for the CLI version too?

@ProkopHapala

the user may be interested in a relatively small scanning region that does not cover the whole system.

I see, make sens

Why bother splitting the code into several scripts unless the output from each of the script can stand on its own? Once the user wishes to view and analyse this force fields separately, it would be desirable that the XSF files include information on the position of atoms and on the lattice vectors.

I agree, I was also considering .xsf files as intermediate result which allows easy debugging and eventually some way to analyze the results. ... Maybe I just don't understand the proper format of .xsf files. I did not saw any problem there. If there is such problem it make sense to correct it.

@ProkopHapala: As for the problems with the XSF format:

The missing atoms and lattice vectors are more an inconvenience rather than an error. Well, actually, some XSF viewers do require the atoms to be present; we have a placeholder hydrogen atom in the XSF file for that purpose. Would be better to have the real atomic structure of the sample there.
More closer to being a real bug is the blind adding of extra points on the boundary when saving the XSF file in our code and removing them when reading these files. This is okay internally for our code as it always adds those files when saving and always removes them when reading, so everything compensates. When reading XSF files generated by an external code, those are potentials or electron densities, typically generated by VASP for a periodic system. In such cases, the extra points are really present too, so it is okay that they get removed. But in OutFz.xsf and the like, they are usually nonsense.

Let me explain here how (to my understanding) the logic with the extra points on the grid cell boundary is supposed to work in the XSF files. First, if the length of one the grid vectors is a=(ax,  ay, az) and there are Na points along that vector, the elementary grid step along that vector is da=(ax,  ay, az)/(Na-1). This is always true. It is part of the definition of the XSF format and it is non-obvious, you can imagine a different format that would have Na instead of Na-1 in the denominator of that definition. For a general grid the dimensions of which have nothing to do with the periodic unit cell, this is end of the story. However, there is a little problem when we want the grid to cover exactly the unit cell. Imagine that a=(ax,  ay, az) is now the lattice vector. We want to sample the cell by Na points along this vector with the grid points being (of course) equally spaced and, for starters, they are supposed to be unique, they do not repeat themselves because of the periodicity. The spacing between the points should of course be da=(ax,  ay, az)/Na under this condition. So what should the corresponding grid vector be? Right, considering the formula that defines the relation between the grid vector and the grid spacing, it has to be a' = a*(Na-1)/Na
But this is inelegant, we would prefer to have a' = a and this is what most codes (but not FHI-AIMS!) generating XSF files for periodic structures chose to enforce. The price to pay is adding a last point along every axis that is a identical copy of the first point by the lattice periodicity. So now, we have Na +1 points instead of Na and the last point is kind of superfluous in terms of information content, but the lattice vectors and grid vectors are the same, which makes us happy, because we can immediately see (looking at the XSF file header) that the grid indeed covers the whole unit cell. So, to some up

When writing the XSF files, the extra points should be added only if the grid covers exactly the entire periodic unit cell, otherwise, they make no sense and are actually wrong (because why should the last point be identical to the first one when you extend a grid that does not fit the periodicity of the structure?).
Similarly, when reading the XSF files, the the end points should be discarded as the extra points only if the grid dimensions coincide with the lattice vectors. Now, the lattice vectors should be read right from the XSF file and compared to the grid vectors read from the same file (the XSF file contains both, if properly written, unlike the CUBE file).

@ProkopHapala Is there any good reason why the order of indices for the grid array is FF[iz,iy,ix] rather than FF[ix,iy,iz] in the CLI version? I used to think this is needed for the CPP parts of the code to be efficient but now as I look deeper into it, that does not seem to be the case.

Is there any good reason why the order of indices for the grid array is FF[iz,iy,ix] rather than FF[ix,iy,iz] in the CLI version? I used to think this is needed for the CPP parts of the code to be efficient but now as I look deeper into it, that does not seem to be the case.

I think efficiency-wise it is rather opposite (we compute each z-stroke independently => better if z is the fastest axes in the array )
I think the reason for FF[iz,iy,ix] ordering was perhaps plotting ? (z-slices), but it is not very good motivation (matplotlib can plot FF[:,:,iz] as well as FF[iz,:,:] ). Maybe it is somehow useful in Fz->df conversion (but perhaps not), or for saving the data to .xsf ?  I don't know. Eventually we may change the order  ... but it would require changes on many places in the code ... co unless there is good reason .... ?
But

@ProkopHapala, thanks for the explanation with respect to the array ordering. As for the Fz->df conversion and saving *.xsf files, I happen to know something about that stuff and no, the reversed index order is not needed for it. In the Fz to df conversion, it does not matter, the conversion is in the end just a convolution of Fz with the appropriate kernel along the z axis and we would literally only have to change axis=0 to axis=2 as an argument to an np.apply_along_axis function at one place in the code in order to adapt the Fz2df function to the natural ordering. In reading and saving *.xsf files, the reversed ordering actually complicates stuff because there is a difference between the CLI and OCL version in the array ordering so the loadXSF and loadCUBE functions need a xyz_order argument which tells them whether they should transpose the array or not.  Now I see that saveXSF does not distinguish between CLI and OCL versions but rather always assumes the reverse order. I did not notice this last fact before. I do not know how it works in the OCL version, perhaps the ordering is really not consistent, arrays which we need to read to XSF are ordered one way, arrays we need to save to XSF the other way and we hope there is nothing we want to read, modify without doing the transposition and then save. I was about to offer to volunteer in changing the ordering so that it would always be FF[ix,iy,iz] but I thought I would not require touching the OCL part. Now that I see the issue affects both CLI and OCL versions, I am not sure I want to do it.

@mondracek As far as I understood, the zyx ordering in the IO functions was mostly because that is how the XSF file format is defined. I specifically added those xyz_order arguments to the functions so that I could get the arrays in the xyz order to use in the OCL code.
It should not be a big change. I think the only places in the OCL code that do IO related things are these two methods: https://github.com/Probe-Particle/ppafm/blob/9f009aec25d8d895f4168f061501211a37a9dd1c/ppafm/ocl/field.py#L192-L195
https://github.com/Probe-Particle/ppafm/blob/9f009aec25d8d895f4168f061501211a37a9dd1c/ppafm/ocl/field.py#L227-L230
The to_file method in particular transposes the array before saving.

@NikoOinonen, thanks for the explanation. So @ProkopHapala was right after all that the likely original motivation of the zyx order in the CLI code was reading and saving XSF files. The native ordering in the XSF file is the opposite of what we'd need, either in CLI or OCL. Seems that historically, the approach in CLI was to accept that ordering and interpret the array indices as ZYX while transpose was performed for OCL. Okay, so we would not have to touch the OCL version at all in order to introduce consistent usage of the XYZ order but thorough changes would be needed in CLI. When done, the I/O functions would not have to differentiate between CLI and OCL and the CLI code would be a bit easier to understand but there is a big danger of introducing errors into the CLI code while implementing the change. Though the errors should be easy to spot by testing, a wrong data order on the grid would destroy the resulting figures completely. What do you think, is it worth the effort? I will not push the change at this moment myself but if anyone else would like it to be done, I am still ready to implement it.

As for the OutFz.xsf files I mentioned earlier in this tread, I see that the inclusion of the sample atomic structure in those files has been already implemented. I was probably looking art files produced by an old version of the code when writing my earlier comments. But the extra points at the scanning region boundary are probably still there.

What do you think, is it worth the effort?

I think it is woth it.

I will not push the change at this moment myself but if anyone else would like it to be done, I am still ready to implement it.

if you implement it, I'm pro :-)
I think it is worth it, but perhaps does not have hi priority.

Though the errors should be easy to spot by testing,

Copy that

authors: NikoOinonen ProkopHapala mondracek

repo: Probe-Particle/ppafm


text:
Error when navigating to nested route in hashbang mode

Reproduced at http://www.webpackbin.com/VJeQCIt7f
Navigating to a route with nested children routes throws

DOMException: Failed to execute 'dispatchEvent' on 'EventTarget': The event is already being dispatched.

Also an intermittent

TypeError: Cannot read property 'toLowerCase' of undefined

Happens on all unhandled routes...
...but closed in 8135bb2bff402f429f17e6024a917be61d650cbc

source: gharchive/issue

authors: barake caseyWebb

repo: Profiscience/ko-component-router

license: WTFPL

license_type: permissive

license_source: github-api


text:
some better error handling, especially in parse_schema and some refactoring in pubsub template

Ich mache denke ich eher ein anderes Ticket weiter, bestimmt kann man am error handling noch einiges verbessern, vor allem im template code. Aber ich denke, dass sollte am besten passieren, nachdem wir da auch logging haben/zusammen mit dem logging.
Ich werd das ticket noch mal zurücktun als error handling in templates.
Ansonsten ist in dem ticket:

parsing eines schemas gibt nun einen error zurück falls etwas schief geht, damit könnte der aufrufer jetzt entscheiden ob er das template ignoreiren will oder panicen (ich denke als standard zu panicen ist erst mal gut im generator, damit wir auch klar sehen können welche sachen wir schon supporten und welche nicht)
hab im pubsub etwas refactored zur besseren lesbarkeit

sehe ich richtig, dass die excalidraw datei nur ein Screenshot ist?

sehe ich richtig, dass die excalidraw datei nur ein Screenshot ist?

Ne, man muss rauszoomen. Das ist aber noch nicht die fertige version. Wollte ich morgen besprechen

source: gharchive/pull-request

authors: doepnern f-eliks

repo: Programmierpraktikum-MVA/AsyncAPI

license: MIT


text:
Add LNTouchDelegate

Background
The LNTouchDelegate that is in the readme file of this project wasn't in the code, I've reimplemented this.
Breaking Changes
There normally shouldn't be any breaking changes.

thanks @brentvvosselen - looks great!  Merging in.

authors: brentvvosselen intere

repo: ProjectDent/ARKit-CoreLocation

license: mit

license_source: bigquery


text:
Category Management Client Side Api

Fixed Issues
#20907,#20910
Design Rename- dialog-component
Files Changed
CategoryController.cs:Method Added CheckDuplicateCategoryNameAsync()
Category.cs: Maxlength Changed to 150
CategoryRepository.cs:Method Added CheckDuplicateCategoryNameAsync() and and method name changed
ICategoryRepository.cs : Method Added CheckDuplicateCategoryNameAsync() and method name changed
CategoryRepositoryTest.cs:Method Name Updated, Add unit test for GetCategoryById and CheckDuplicateCategoryName
categories.service.ts:addCategory updateCategory Method Added
StringConstants.cs:Added CategoryNameExistsError
IStringConstants.cs:Added CategoryNameExistsError
add-category-dialog.html : Added Data binding and bind button with function
questions-dashboard.component.ts : Rename- dialog-component added
questions-dashboard.html:Added Data binding
rename-category-dialog.component.ts: updateCategory Method Added
rename-category-dialog.html: Added Data binding and bind button with function
Checks

[x] Naming Conventions
[x] Server side code comments (proper English, grammar, and no spelling mistakes)
[x] Client side code comments (proper English, grammar, and no spelling mistakes)
[x] Unused variables, methods, blank spaces and namespaces.
[x] Optimal Code and code formatting
[x] Commit History is proper, no merge is done.
[x] Commit/pull request messages should be proper to justify your feature
[x] All test cases are executed provided by the tester.

There is a problem in PR. Please rebase it properly.

SonarQube analysis reported 7 issues

 4 critical
 1 major
 2 minor

Watch the comments in this conversation to review them.

SonarQube analysis reported 1 issue

 1 major

Watch the comments in this conversation to review them.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 CategoryRepositoryTest.cs#L14: Remove the "_bootstrap" field and declare it as a local variable in the relevant methods.

Please write comments in proper English statements.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 CategoryRepositoryTest.cs#L14: Remove the "_bootstrap" field and declare it as a local variable in the relevant methods.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 CategoryRepositoryTest.cs#L14: Remove the "_bootstrap" field and declare it as a local variable in the relevant methods.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 CategoryRepositoryTest.cs#L14: Remove the "_bootstrap" field and declare it as a local variable in the relevant methods.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 CategoryRepositoryTest.cs#L14: Remove the "_bootstrap" field and declare it as a local variable in the relevant methods.

Commit message should be proper.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 CategoryRepositoryTest.cs#L14: Remove the "_bootstrap" field and declare it as a local variable in the relevant methods.

SonarQube analysis reported 1 issue

 1 major

Watch the comments in this conversation to review them.

SonarQube analysis reported 1 issue

 1 major

Watch the comments in this conversation to review them.

SonarQube analysis reported 1 issue

 1 major

Watch the comments in this conversation to review them.

authors: Krunal-Promact chintans spartha1995

repo: Promact/trappist


text:
Connection not changed

based on you comments to https://github.com/ProtonMail/go-imap-id/tree/user_set_id
here https://github.com/ProtonMail/go-imap-id/blob/master/server.go#L34
the retype is never succesfull. The argument conn is never extended with id ID.

I cannot reproduce. Here's the test snippet I used:
package main

import (
	"log"
	"time"

	"github.com/emersion/go-imap/server"
	"github.com/emersion/go-imap/backend/memory"
	"github.com/ProtonMail/go-imap-id"
)

func main() {
	// Create a memory backend
	be := memory.New()

	// Create a new server
	s := server.New(be)
	s.Addr = ":1143"
	// Since we will use this server for testing only, we can allow plain text
	// authentication over unencrypted connections
	s.AllowInsecureAuth = true

	s.Enable(id.NewExtension(id.ID{}))

	go func() {
		c := time.Tick(1 * time.Second)
		for range c {
			s.ForEachConn(func (conn server.Conn) {
				if conn, ok := conn.(id.Conn); ok {
					log.Printf("Got an id.Conn: %T\n", conn)
				}
			})
		}
	}()

	log.Println("Starting IMAP server at localhost:1143")
	if err := s.ListenAndServe(); err != nil {
		log.Fatal(err)
	}
}

Sorry, I misunderstood the issue. Fixed by https://github.com/emersion/go-imap/commit/4b279518de2b465217fd32b079e0680a7cf499ff

authors: cuthix emersion

repo: ProtonMail/go-imap-id


text:
fix compilation and a few clippy lints

The lib failed to compile on my version of rust (stable 1.58), so I went ahead and fixed the errors

Thanks!

authors: Protryon greaka

repo: Protryon/klickhouse


text:
🛑 Service - Pterodactyl is down

In 179ee66, Service - Pterodactyl (https://pterodactyl.proxeuse.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Service - Pterodactyl is back up in 9e2b7a7 after 6 minutes.

repo: Proxeuse/status


text:
Basic example does not run on Ubuntu 20.04+GTX760

./basic
2020/12/24 09:13:22 LOG	: Renderer	: OpenGL		: Version: 4.5.0 NVIDIA 440.100
2020/12/24 09:13:22 ERROR	: Shader	: BackBufferShader	: Loading source: Couldn't compile Fragment Shader: 0(37) : error C7533: global variable gl_FragColor is deprecated after version 120

2020/12/24 09:13:22 LOG	: Texture	: Gopher	: Finished loading! W: 245 H: 300 T: 0.004 s
2020/12/24 09:13:22 LOG	: Shader	: 2D	: Finished Loading!

I am sorry I did not see that there was an issue opened. The problem seems to be that gl_FragColor is no longer available. I would need to change all occurences to something like out vec4 fragColor. But I am not actively working on the engine

license: Zlib


text:
Add “Loading..” note for each table on Patient Summary page.

Add “Loading..” note for each table on Patient Summary page. We suppose it can look like this in each table while it is loading http://prntscr.com/hw0tt3 and in case there are no results user will see such note http://prntscr.com/hw0vc5 .

done

repo: PulseTile/PulseTile


text:
Anvil options for repairing and damaging

This patch allows for repairing anvils using iron ingots and damaging them using obsidian.

I have made the requested changes and added sounds since it was kinda dull without them.

repo: PurpurMC/Purpur


text:
🛑 Gitea is down

In 326a82e, Gitea (https://git.pxlbuzzard.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Gitea is back up in e371403.

repo: PxlBuzzard/upptime


text:
Feature: Proposed feature in upcoming version

Proposed Feature in Upcoming version(Draft)

Data should be generated based on Gender. fname file will be rewritten. There will be 2 files.

fname_male.txt
fname_female.txt

Generate Geo Coordinate, should be from the same city.

40° 43' 50.1960'' N and 73° 56' 6.8712'' W.

Generate Father/Mother's name as well in the profile section.

fname_male.txt and fname_female.txt` will be required for this task

Generate fake Credit/Debit Card

3774-1517-3429-7001, 07/29

with the job title there should be job experience it should match with age 😁.

output key name - job_experience

Current Output Format
{
  "first_name": "Kyler",
  "last_name": "Mcclain",
  "hair_color": "brown",
  "blood_type": "(AB-)",
  "full_name": "Kyler Mcclain",
  "DOB": "10/11/1953",
  "age": 69,
  "height": 199,
  "weight": 106,
  "phone": "+1-405-968-1870",
  "address": "268 Pearl St. South Park IL 19112",
  "email": "kylermcclain@usa.com",
  "job_title": "School Teacher",
  "ip_address": "189.214.121.77"}

@ExpressHermes Thanks for the suggestion and your input on the proposed features.

Hey, @codePerfectPlus , could you please assign mne to this issue? Would like to work on it in the comming days :)

@DavidCano98 There are 5 issues, please let me know on which issues you want to contribute. I have added more details about the task. we can discuss more if needed. Please suggest if there is anything that needs to improve in the task.

I'd actually like to contribute to all 5 points in this issue. And also yes, I can see the description has been updated, thank you for the details.

btw @codePerfectPlus , I sent you (I assume it's you) a friend request on Discord where I'd like to ask about a few things, could you please accept when you are able to?

@DavidCano98 I didn't get any friend requests. I am sharing my discord ID
soundsLikecrazy#9794

repo: Py-Contributors/RandomProfileGenerator


text:
Redo of #PR215

Because I made a mess of PR https://github.com/PySport/kloppy/pull/215, here is a clean attempt.
It includes updated jsonl loader without with open(), Dries' minor changes to IDs as proposed in https://github.com/PySport/kloppy/commit/277a7143566df9f05cef5b1d66a353cadcb0f4ba and updated event_factory.

Thanks, @UnravelSports! The changes to the SkillCorner deserializer look good to me.
Could you please fix the code formatting? I suspect that the formatting changes to the event data deserializers were unintentional.

@UnravelSports I've managed to make the necessary changes myself. 😊

@JanVanHaaren for future reference, what formatting was wrong? Because I did run black on all the files, so kinda curious where it went wrong
Thanks for fixing it and approving of the changes!

@JanVanHaaren for future reference, what formatting was wrong? Because I did run black on all the files, so kinda curious where it went wrong

Good question. I suspect that you're using a different version of black that has slightly different default preferences, but I'm  not entirely sure.

Good point, I'll update :)

authors: JanVanHaaren UnravelSports

repo: PySport/kloppy


text:
Tokenize repeating dots and commas from numbers (fix #461)

What does this changes
I change a rule of _RE_NONTHAI in newmm and multi_cut.

How this fixes it
Add rule of float number and number.
Fixes #461
Your checklist for this pull request
🚨Please review the guidelines for contributing to this repository.

[x] Passed code styles and structures
[x] Passed code linting checks and unit test

Coverage remained the same at 95.742% when pulling abd9769935ebe2f2c50ae1d46b58a00fda8d5975 on fix-461 into c7a37b23cffc76ae636bc135a2447b90638c06a5 on dev.

Colab: https://colab.research.google.com/drive/1OcC7mCwAQQvx7qC9o6DdXcre7V4ohCtp?usp=sharing

Hello @wannaphong! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file pythainlp/tokenize/multi_cut.py:

Line 129:80: E501 line too long (83 > 79 characters)
Line 147:80: E501 line too long (83 > 79 characters)

Nice work. Can we add test cases for this?
May be something like:
* "19..." -> ['19', '...']

* "19." -> ['19', '.']

* "19.84" -> ['19.84']

* "127.0.0.1" -> ['127.0.0.1']

* "USD1,984.42" -> ['USD', '1,984.42']

OK

I think the code and the test cases themselves are good (thanks), but the problem is around coverall for macOS hmm..

authors: bact coveralls pep8speaks wannaphong

repo: PyThaiNLP/pythainlp


text:
[feat] Attemp to find a better way to seriable preprocess

What does this PR do?

Fixes # (issue)
Before submitting

[ ] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests? [not needed for typos/docs]
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review

[ ] Is this pull request ready for review? (if not, please submit in draft mode)

Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

Hello @tchaton! Thanks for updating this PR.

In the file flash/data/process.py:

Line 340:13: E722 do not use bare 'except'
Line 344:13: E722 do not use bare 'except'
Line 349:13: E722 do not use bare 'except'

repo: PyTorchLightning/lightning-flash


text:
URL to bug report is incorrect in Github issue template

📚 Documentation
When creating a new Github issue, the link to the BoringModel is incorrect and needs to be updated.
Existing (incorrect link):
<!--
Please reproduce using the BoringModel!
...
or this simple template:
https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pl_examples/bug_report_model.py

Updated link:
https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pl_examples/bug_report/bug_report_model.py

Since this is an issue with the Github issue template, I don't think I can create a PR/fix for it.
cc @borda

@Shreeyak Thank you for reporting the issue. You can still submit a PR to fix the link. The file is here: https://github.com/PyTorchLightning/pytorch-lightning/blob/master/.github/ISSUE_TEMPLATE/bug_report.md
Would you be interested in creating a PR for it?

It seems like there is another place we need to fix the link:
$ grep -rn pl_examples/bug_report .
docs/source/advanced/fault_tolerant_training.rst:137:On tiny models like the `BoringModel and RandomDataset <https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pl_examples/bug_report_model.py>`_
.github/ISSUE_TEMPLATE/bug_report.md:23:https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pl_examples/bug_report_model.py

authors: Shreeyak akihironitta

repo: PyTorchLightning/pytorch-lightning


text:
unable to call  validation_step

🐛 Bug
I follow the doc to evaluate my model at each step. It did not work; the validation_step is never called even though I  have defined the validation_step in my model.
def validation_step(self, batch, batch_idx):
        """validation
        Args:
            batch (_type_): _description_
            batch_idx (_type_): _description_

        Returns:
            dict of evaluation metrics.
        """
        print("!")
        for inputs in batch:
            aa_seq = inputs["base"]["seq"][0]
            msa_tokens = inputs["feat"]["msa-t"][:, 0, :].unsqueeze(1)  # only use the first seq (bs, 1, msa_len)
            t1ds_tns = inputs['feat']['t1ds'] # dummy tensor
            t2ds_tns = inputs['feat']['t2ds']
            output = self.model(
                msa_tokens, t1ds_tns, t2ds_tns, is_3d=True, aa_seq=aa_seq
            )
            output = output[-1]
            result_dict = evaluate(
                inputs,
                output_3d=output,
                metrics = ["gdt_ts", "tm_scr", "lddt", "lddt_ca", "lddt_bb", "lddt_check"],
                pred_folder = self.hyper_params.get("pred_folder",'../tmp_pred_pdb'),
                ref_folder = self.hyper_params.get("ref_folder",'../tmp_ref_pdb'),
            )
            # loss, metrics_af2 = self.loss_helper.calc_loss(inputs, output)
            # metrics_af2.update({"loss": loss})
            # self.log_metrics_af2(metrics_af2)
            self.log_eval_metric(result_dict)
        return result_dict

and my trainer:
trainer = pl.Trainer(
        overfit_batches = 6,
        default_root_dir=exp_dir,
        # accelerator=hparams["accelerator"],
        gpus=hparams["gpus"],
        max_epochs=hparams["max_epochs"],
        log_every_n_steps=hparams["log_every_n_steps"],
        # val_check_interval=1,
        callbacks=[
            EarlyStopping(
                "loss", patience=hparams["patience_ratio"] * hparams["max_epochs"]
            ),
            ModelCheckpoint(
                dirpath=exp_dir,
                filename="{epoch}-{loss}",
                save_top_k=hparams["save_top_k"],
                mode="min",
                monitor="loss",
            ),
        ],
        logger=wandb_logger,
    )
    log_config(hparams, wandb_logger, trainer)
    train_loader = get_dataloader(hparams)
    val_loader = get_dataloader(hparams)
    trainer.validate(model,val_loader)
    trainer.fit(model, train_loader, val_loader)

Any ideas?

To Reproduce

Expected behavior

Environment

PyTorch Lightning Version (e.g., 1.5.0):
PyTorch Version (e.g., 1.10):
Python version (e.g., 3.9):
OS (e.g., Linux):
CUDA/cuDNN version:
GPU models and configuration:
How you installed PyTorch (conda, pip, source):
If compiling from source, the output of torch.__config__.show():
Any other relevant information:

Additional context

thanks. I works~May I ask the difference? I think the two keywords plays the same role..

thanks so so so much. Perfect explainations.


text:
automatically override progress_bar_refresh_rate in google colab

🚀 Feature

If running on google colab, automatically assign progress_bar_refresh_rate=20 if the user didn't override the default of 1.
Motivation
Google colab is notorious for crashing because of the tqdm progress bar while training. We usually solve that by assigning a larger number to progress_bar_refresh_rate flag of Trainer. However, this is super annoying since you have to do it all the time.
Also, when writing up examples for beginners, it would be nice to just say pl.Trainer() instead of having to pass the refresh rate flag, as that may confuse newcomers.

Pitch

Put this logic in CallbackConnector, or ProgressBarBase. I'm not sure which makes more sense.
import sys

def check_if_on_google_colab():
    return 'google.colab' in sys.modules

Alternatives

Additional context

Yes please, this is nice. It crashes my whole Chrome if I forget it, it's annoying.
I would put it into the callback connector for the default case because in the progressbarBase it could override the settings if a user has a custom bar and that's probably undesired?

authors: awaelchli nateraw


text:
Allow separate config files for parameters with class type when LightningCLI is in subclass_mode=False

What does this PR do?
This enables the possibility of having separate config files for parameters whose type hint is a class when the LightningCLI is in subclass_mode=False. For subclass_mode=True this option is enabled by default so this change also makes it more consistent.
For example for a CLI like:
from torchaudio.transforms import MelSpectrogram
from pytorch_lightning.utilities.cli import LightningCLI
import pytorch_lightning as pl

class PrxMelDataModule(pl.LightningDataModule):
    def __init__(self, mel_spec: MelSpectrogram):
        ...

class HifiGAN(pl.LightningModule):
    def __init__(self, mel_spec: MelSpectrogram):
        ...

if __name__ == "__main__":
    LightningCLI(
        model_class=HifiGAN,
        datamodule_class=PrxMelDataModule,
    )

it would be possible to have a config like:
data:
  mel_spec: mel_spec_config.yml
model:
  mel_spec: mel_spec_config.yml

Fixes https://github.com/omni-us/jsonargparse/issues/95#issuecomment-944367550
Does your PR introduce any breaking changes? If yes, please list them.

Before submitting

[x] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[x] Did you list all the breaking changes introduced by this pull request?
[x] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

Dear @mauvilsa,
We are releasing v1.5 by tomorrow. Do you believe you could get this PR by then ?
Best,
T.C

We are releasing v1.5 by tomorrow. Do you believe you could get this PR by then ?

Yes, sure. This is a small change.

authors: mauvilsa tchaton


text:
sync 1.1.2 >> feature 1.2 [full merge, no squash]

What does this PR do?
Just to try if we can have all diff commits listed even after resolving conflicts...
effectively it is just a draft, but to see collision it has to be full PR, so ignore it atm
closes #5251
Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes [if needed]?
[x] Did you write any new necessary tests [no need for typos, docs]?
[x] Did you verify new and existing tests pass locally with your changes?
[x] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified
[x] Check that target branch and milestone are aligned!

Did you have fun?
Make sure you had fun coding 🙃

rebase on release/1.2-dev and resolved conflicts...

@SeanNaren @tchaton so shall we merge it as with all commits or squash?
as the collisions were quite minimal I would rather try plain commits...

the failer is unrelated nad the hotfix is in #5352

the failer is unrelated nad the hotfix is in #5352


text:
Use more secure base image

Change base image to registry.access.redhat.com/ubi8/python-38 or registry.access.redhat.com/ubi8

registry.access.redhat.com/ubi8/python-38
registry.access.redhat.com/ubi8

Closed with #56

repo: Pyrrha-Platform/Pyrrha-Rules-Decision


text:
Not handling nested lists

input_str = """
We would like to study about states of matter\n
Matter\n

Solid

Ice cream
mobile
board etc.

Liquid

Water

Gas

Air

"""

out_put = markdown.markdown(input_str)
print(out_put)
The input string has nested lists, but when I convert it to html using markdown, the nested lists are displayed as single list.
We would like to study about states of matter
Matter

Solid
Ice cream
mobile
board etc.
Liquid
Water
Gas
Air

You are not indenting nested list to 4 spaces like the documentation states is required:
import markdown

input_str = """
We would like to study about states of matter\n
## Matter

- Solid
    - Ice cream
    - mobile
    - board etc.
- Liquid
    - Water
- Gas
    - Air

"""

out_put = markdown.markdown(input_str)
print(out_put)

"""

We would like to study about states of matter

Matter

Solid

Ice cream

mobile

board etc.

Liquid

Water

Gas

Air

"""

We would like to study about states of matter
Matter

Solid
Ice cream
mobile
board etc.

Liquid
Water

Gas
Air

As @facelessuser states, this behavior is documented. You can find that here. As this is the intended behavior, I am closing this.

Unfortunately, some Markdown sources do use three spaces for indented lists. For example, LLM-generated replies often use three spaces (likely because their training material included such content).
While I understand the four-space expectation is documented, it would be nice to have an option to relax the requirement for less well-behaved data sources.

It should be noted that Python Markdown is not meant to parse every Markdown convention out in the wild. Python Markdown is also an old-school Markdown parser, not a CommonMark parser.  With that said, extensions can be created to override the default list behavior, and IIRC there are probably some already out there that are more forgiving with indentation. I don't have time to hunt examples right now though, and I also don't know if they have other side effects, but I'm fairly certain there are some extensions out there that attempt to address the indentation to be more forgiving.

@mitya57 - the tab_length setting works perfectly - thank you!
In our application, the LLM (OpenAI GPT-4o) generates responses that align list sublist item to the parent item's start-of-content:
9. This is item 9.
   - This is a sublist item.
10.  This is item 10.
    - This is a sublist item.

Setting tab_length=3 handles both cases perfectly.

authors: Knamdev chrispy-snps facelessuser waylan

repo: Python-Markdown/markdown


text:
Find selector for variable type

https://github.com/QCDIS/NaaVRE/blob/464ccdf61d01fbafedcd85a7b0b7f6eaef645882/cypress/e2e/launcher.cy.ts#L94

022003ab76ee69cc87fccb6fbb0c0eb314f1f68c adds the selector and the container creation for first cell.
Required to update Cypress version (4e18711ee90f42a4aaad2e4d381889400f6cbe5e) and a small fix to the cell creation (5efa7c251ebcc3786dbfbe5340073c40bb6dc961).
But #734

repo: QCDIS/NaaVRE


text:
Implement more QEC experiments

This PR introduces more QEC experiments in the notebooks/ folder in order to test in real conditions the tqec package and validate it on more involved examples.
The final goal of this PR is to obtain a scalable experiment represented by the "corner":

Initialise a logical qubit
Extend it vertically and horizontally to obtain the "corner" shape
Move the logical qubit by performing the needed measurements
Measure the observable on the moved logical qubit

Marking this PR as ready for review. More QEC experiments will be implemented to fix #50, #51, #52 and #53, but I think it is better to have one PR for each of the issues.

Are you looking for feedback on the quality of the experiments themselves?

I suggested these experiments :-)
On Wed, Jan 17, 2024 at 3:44 PM Sam Burdick @.***>
wrote:

Are you looking for feedback on the quality of the experiments themselves?
—
Reply to this email directly, view it on GitHub
https://github.com/QCHackers/tqec/pull/44#issuecomment-1897492879, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKAXTGWWAD5V3IBSI44QJ3YPBO5PAVCNFSM6AAAAABB4RIPUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXGQ4TEOBXHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I suggested these experiments :-)

I added a note about that, sorry for not including it in the first place.

I need to check that the auto-merging did not break anything, I will post a new comment when this is ready for merging.

The main notebook of this PR, notebooks/logical_qubit_extended_memory_experiment.ipynb, is still running smoothly without any noticeable change.
I would be in favor of merging this PR, as previously noted.
Just waiting for approval to merge.

Ready to merge, waiting for an accept from someone to be able to merge.

Fix #37, still waiting for someone to approve to let me merge.

@inmzhang would you mind checking if this PR can be merged?

Sure, I will come back and review this in half an hour.

authors: afowler inmzhang nelimee smburdick

repo: QCHackers/tqec


text:
EnderIO ITool should eventually be reimplemented into the modules themselves...

Currently ITool is implemented in ItemPowerFist and is manipulated per each module via NBT flags, which allows transparent facades to toggle.
This technically should be implemented in the modules themselves using mapped traits (as the OmniWrench does in net.machinemuse.api.OmniWrench), however the NBT method is effective and works properly.
I plan on reimplementing this in the planned release that will come after my upcoming push to MPSA.

Oops, forgot to close this. This has been taken care of as of 0.11.0.7-QMX.

repo: QMXTech/MachineMusePowersuits


text:
questions about grouth.npz

hi
thank you for sharing your excellent work!
I am trying to make my ground_truth.npz for my own dataset. but I have some questions:

does 'utmQ' and 'utmQ' contains the utm coordinates of all pictures in query and database dataset?
I have create my datasets with 7 places. Each place have 400 pictures for database and 80 pictures for query. is the number of pictures enough for training (simply using the traning code provided for maliipary dataset)?
I have try training on my own dataset (descirbed in question 2.). And I got the following result:

====> Calculating recall @ N
====> Recall@1: 0.0600
====> Recall@5: 0.1200
====> Recall@10: 0.1800
====> Recall@20: 0.3000
====> Recall@50: 0.6000
====> Recall@100: 0.8200
I wonder the result is good or not?
I am looking forward to your reply , thank you!

Hi,

Yes
No, this is most likely not sufficient. But why not use a pre trained model and use that to extract features on your dataset?
The results look poor considering there are only 7 places.

You might want to read our recent “Visual Place Recognition: A Tutorial” paper for some more intuitions.

authors: Tobias-Fischer WentangChen

repo: QVPR/Patch-NetVLAD


text:
Activity被回收，无法重新建立activity

android:launchMode="standard"
A->B->C三个activity,按返回键，只能回退到B，然后直接到主工程，因为A被onDestroy掉了，但正常逻辑这时应该是重走A的onCreate()流程，必现的，跟机型无关。

修改一下 坑位数量就可以了。
详见：
https://github.com/Qihoo360/RePlugin/blob/dev/replugin-host-gradle/src/main/groovy/com/qihoo360/replugin/gradle/host/handlemanifest/ComponentsGenerator.groovy

authors: cundong jaydon


text:
Behavior when root job is canceled before session activates

URL, if applicable
These seem applicable (the former links to the latter so maybe only documenting it in one of those places is necessary).
https://qiskit.org/ecosystem/ibm-runtime/sessions.html#what-happens-when-a-session-ends
https://qiskit.org/ecosystem/ibm-runtime/how_to/run_session.html#close-a-session
Describe the new content you are requesting.
For the ibm_cloud pay-go channel, the scheduler is going to be making a behavior change [1] such that if the root/first job in a session is canceled before it runs and activates the session, the session will be closed and any remaining queued jobs in that session will be marked as Failed. This is similar to what happens today if a user explicitly closes their session before all jobs are run or if the session closes due to the max time expiring and there are still remaining queued jobs in the session.
Similarly, there are plans to make the same behavior change in the ibm_quantum (IQP) channel [2].
We hope to have both changes done in October but let's hold off on publishing docs around this until we have the changes in production for both cloud pay-go and IQP channels.
[1] https://github.ibm.com/IBM-Q-Software/multi-channel-scheduler/pull/1267
[2] https://github.ibm.com/IBM-Q-Software/sw-api-queue/issues/3163
If this new content request is accepted, do you want to write the content?
I only want to review the material when it's finished

Thanks @mriedem! Let us know when the changes in production are near.

The related change has been merged to IQP and should be in production next Monday Nov 13. The behavior is slightly different in the IQP channel in that if the root job is canceled at any point, even if it's running or already completed, the session will be closed and remaining queued jobs will be marked as Failed. That's slightly different from the ibm_cloud channel implementation which only closes the session if the root job is canceled before it ever runs - if the root cloud job is running and then canceled we don't close the cloud pay-go session.
For the purposes of documenting this behavior I doubt you want to get into those details, so maybe it's sufficient to just say that canceling the root job in the session (the job which has the same ID as the session) will close the session and fail any remaining queued jobs in the session.

@beckykd does this need to be tracked on the Cloud side?

authors: abbycross mriedem

repo: Qiskit/documentation


text:
Split visualization page into three

Continuation of #971

The circuit visualizations are most valuable in the build stage of the circuit. This splits the results visualization into a separate file for the analysis/post-processing stage. Additionally, it makes sense to split the quantum information visualizations into the verify (or learning) step.

Preview quick links

analyze/visualize-results
build-new/circuit-visualization
build-new/plot-quantum-states

Oh dear - I see we have both statevector and state vector all throughout our docs, when I do a search! So I don't even know which one to suggest you change to in this PR.... 👀

@abbycross

Oh dear - I see we have both statevector and state vector all throughout our docs, when I do a search! So I don't even know which one to suggest you change to in this PR.... 👀

I think the "correct" term is state vector, but statevector is a common compouding that happens quite a lot within Qiskit (e.g. we called the class Statevector rather than StateVector).
IIRC we discussed this at some point with Jennifer and Becky and decided to double down on the compounding and go with "statevector", but I'm not 100% sure about that and can't find the conversation. I've changed all instances in this PR to statevector for now but we can easily switch back if needed.

@abbycross

Oh dear - I see we have both statevector and state vector all throughout our docs, when I do a search! So I don't even know which one to suggest you change to in this PR.... 👀

I think the "correct" term is state vector, but statevector is a common compouding that happens quite a lot within Qiskit (e.g. we called the class Statevector rather than StateVector).
IIRC we discussed this at some point with Jennifer and Becky and decided to double down on the compounding and go with "statevector", but I'm not 100% sure about that and can't find the conversation. I've changed all instances in this PR to statevector for now but we can easily switch back if needed.

I remember we had a conversation too but couldn't find where we landed with it! I'm good to leave it compounded.

authors: abbycross frankharkins


text:
Portuguese localization PRs from GitLocalize fail automated checks.

Steps to reproduce the problem
After finalizing the translation review submit a PR from GitLocalize.
What is the current behavior?
PRs #1117 and #1118 seem to fail the automated checks with errors Error: Cypress tests: 1 failed and Error: buildx failed with: error: denied: You have exceeded your storage quota. Delete one or more images, or review your storage quota and pricing plan. For more information, see https://ibm.biz/BdPdFA. respectively.
Unsure if this is a bug related to GitLocalize or the repo itself.
What is the expected behavior?
PRs sent from GitLocalize should pass the automated checks without any errors.
Screenshots
No response
Device
No response
OS
No response
Browser
No response
Additional information
No response

Hi @MarcoBarroca. the error was solved and the two PRs already merged. Can we close this issue? Thank you!

No problem, closing.

repo: Qiskit/platypus


text:
DensityMatrix.from_instruction fails after measurement

Environment

Qiskit Terra version: 0.23.2
Python version: 3.8.10
Operating system: Google Colab

What is happening?
DensityMatrix.from_instruction fails after measurement.
How can we reproduce the issue?
import qiskit
from qiskit.quantum_info import DensityMatrix

circuit = qiskit.QuantumCircuit(1, 1)
print(DensityMatrix.from_instruction(circuit))
circuit.measure(0, 0)
print(DensityMatrix.from_instruction(circuit))

The second print fails with

QiskitError: 'Cannot apply instruction with classical bits: measure'

What should happen?
I expect the density matrix of the mixed state after measurement, according to https://qiskit.org/textbook/ch-quantum-hardware/density-matrix.html#mixed
Any suggestions?
While I can use QuantumCircuit.save_density_matrix, it returns empirical measurements. E.g., if the true matrix entry is 1/2, it can return 0.496 due to variance.

My understanding is that the Statevector class and the DensityMatrix class from quantum_info do not support measurements (non-unitary operations in general) by design, so this isn't really a bug.
The description given in the qiskit textbook is simply an example of how the density matrix represents the "lack of knowledge" of a given state, which is expressed in terms of classical probabilities. Performing a measurement isn't really necessary to demonstrate this. It is equally valid to say that you have "lost access" to q1 or simply ignored it. This can be properly simulated using the partial_trace function to trace out q1.

authors: diemilio dyukha

repo: Qiskit/qiskit-terra


text:
Provide type hints to quantum info

Summary
Added type hints to classes under quantum_info
Details and comments
This PR is related to https://github.com/qiskit-advocate/qamp-spring-23/issues/24.

Pull Request Test Coverage Report for Build 4966863177

371 of 378 (98.15%)  changed or added relevant lines in 70 files are covered.
15 unchanged lines in 6 files lost coverage.
Overall coverage increased (+0.05%) to 85.951%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/quantum_info/operators/operator.py
20
21
95.24%

qiskit/quantum_info/operators/pauli.py
0
1
0.0%

qiskit/quantum_info/synthesis/cnotdihedral_decompose.py
0
1
0.0%

qiskit/quantum_info/operators/channel/superop.py
13
15
86.67%

qiskit/quantum_info/operators/symplectic/pauli.py
19
21
90.48%

Files with Coverage Reduction
New Missed Lines
%

qiskit/quantum_info/operators/pauli.py
1
0%

qiskit/quantum_info/synthesis/cnotdihedral_decompose.py
1
0%

qiskit/extensions/quantum_initializer/squ.py
2
80.0%

crates/accelerate/src/vf2_layout.rs
3
94.74%

crates/accelerate/src/sabre_swap/layer.rs
4
97.32%

crates/qasm2/src/lex.rs
4
91.14%

Totals

Change from base Build 4961195397:
0.05%

Covered Lines:
71344

Relevant Lines:
83005

💛  - Coveralls

Thanks. Mixin classes don't have the type hint. Why do not you add them?

I added type hints to meta classes in 69d3d9e.

authors: coveralls derwind


text:
Fix clifford simulator run for qobj

Summary
The qobj conversion for the clifford simulator was incorrectly treating
a qobj object as a dict and trying to access it like one. This commit
fixes this by converting an input qobj object into a dict, performing
the transforms and then making a new qobj from that dict to pass to
run().
Details and comments
Fixes #1119

did we close on this. It looks good to me

I'd like to have an answer to https://github.com/Qiskit/qiskit-terra/pull/1125#discussion_r227328361, in the inline comments.

Im inclined to include this as you found an issue. The Clifford is not official supported and will be part of aer 0.2 with some test and until then when we find a issue we should just fix it.

authors: diego-plan9 jaygambetta mtreinish


text:
Improve runtime scaling for transpiler optimization level 2 and 3

What should we add?
This is the tracking epic for the work to improve the runtime scaling performance for the transpiler's optimization level 2 and level 3. It generally scales linearly with the number of gates but some of the passes we run in the higher optimizations have high constant factors which make the total execution slow. We'll add sub-issues here as we do more investigation and profiling to get to the bottom of the bottlenecks and identify things to speed up:
### Tasks
- [ ] https://github.com/Qiskit/qiskit/issues/8774

We can close this now that we've merged #12010 and all it's follow on PRs. Also the other performance work on improving transpiler runtime especially #13091 have made level 2 and 3 much more scalable.

repo: Qiskit/qiskit


text:
qiskit.execute() does not use the scheduling_method argument

Environment

Qiskit version: 0.34.1
Qiskit Terra version: 0.19.1
Python version: 3.8.2
Operating system: Ubuntu 20.04 (via Windows WSL)

What is happening?
I'm attempting to queue circuits to run on the devices that involve delays before the measurements. If I send a circuit with a delay then I may receive the error message:
TranspilerError: "This circuit None may involve a delay instruction violating the pulse controller alignment. To adjust instructions to right timing, you should call one of scheduling passes first. This is usually done by calling transpiler with scheduling_method='alap'."
If I try running qiskit.execute with the argument scheduling_method='alap' as suggested then I receive the same error. Furthermore if I try to pre-transpile the circuit with qiskit.transpile with the same scheduling method argument and try to execute the transpiled circuit I get the same error.
How can we reproduce the issue?
IN
from qiskit import QuantumCircuit, execute, IBMQ, transpile

backend = reservation_provider.backend.ibmq_casablanca

test_circ = QuantumCircuit(1)
test_circ.x(0)
test_circ.delay(20, unit="dt")
test_circ.measure_all()

test_circ.draw()

OUT
        ┌───┐┌───────────────┐ ░ ┌─┐
     q: ┤ X ├┤ Delay(20[dt]) ├─░─┤M├
        └───┘└───────────────┘ ░ └╥┘
meas: 1/══════════════════════════╩═
                                  0

IN
test_job = execute(test_circ, backend=backend, shots=10000)

OUT
Above error

IN
test_job = execute(test_circ, backend=backend, shots=10000, scheduling_method='alap')

OUT
Above error

IN
# pre-transpile the circuit
test_circ_transpiled = transpile(test_circ,backend=backend, scheduling_method='alap')
test_circ_transpiled.draw()

OUT
                      ┌───┐        ┌───────────────┐ ░ ┌───────────────┐┌─┐
      q_0 -> 0 ───────┤ X ├────────┤ Delay(20[dt]) ├─░─┤ Delay(12[dt]) ├┤M├
               ┌──────┴───┴───────┐└───────────────┘ ░ └───────────────┘└╥┘
ancilla_0 -> 1 ┤ Delay(26704[dt]) ├──────────────────────────────────────╫─
               ├──────────────────┤                                      ║
ancilla_1 -> 2 ┤ Delay(26704[dt]) ├──────────────────────────────────────╫─
               ├──────────────────┤                                      ║
ancilla_2 -> 3 ┤ Delay(26704[dt]) ├──────────────────────────────────────╫─
               ├──────────────────┤                                      ║
ancilla_3 -> 4 ┤ Delay(26704[dt]) ├──────────────────────────────────────╫─
               ├──────────────────┤                                      ║
ancilla_4 -> 5 ┤ Delay(26704[dt]) ├──────────────────────────────────────╫─
               ├──────────────────┤                                      ║
ancilla_5 -> 6 ┤ Delay(26704[dt]) ├──────────────────────────────────────╫─
               └──────────────────┘                                      ║
       meas: 1/══════════════════════════════════════════════════════════╩═
                                                                         0

IN
test_job = execute(test_circ_transpiled, backend=backend, shots=10000)

OUT
Above error

IN
test_job = execute(test_circ_transpiled, backend=backend, shots=10000, scheduling_method='alap')

OUT
Above error

What should happen?
I expect the execute functions to finish running in a few seconds and for the job to be queued up to run on the device.
Any suggestions?
I noticed in the traceback that when the execute function transpiles a circuit to run on the device it doesn't seem to use the scheduling_method argument, see lines 292-303 of qiskit/execute_function.py in my installation
    else:
        # transpiling the circuits using given transpile options
        experiments = transpile(
            experiments,
            basis_gates=basis_gates,
            coupling_map=coupling_map,
            backend_properties=backend_properties,
            initial_layout=initial_layout,
            seed_transpiler=seed_transpiler,
            optimization_level=optimization_level,
            backend=backend
        )

I tried making this edit to my local installation
    else:
        # transpiling the circuits using given transpile options
        experiments = transpile(
            experiments,
            basis_gates=basis_gates,
            coupling_map=coupling_map,
            backend_properties=backend_properties,
            initial_layout=initial_layout,
            seed_transpiler=seed_transpiler,
            optimization_level=optimization_level,
            backend=backend,
            scheduling_method=scheduling_method # <-----Added by me
        )

and the code in the MWE above ran without errors, with my jobs getting queued and running with the expected results.
I'm hesitant to make a pull request with this change in case this causes problems elsewhere but it definitely solves my problem.

+1, I've also encountered this error.

Actually the following works for me with Qiskit Terra version 0.19.2
test_circ_transpiled = transpile(test_circ,backend=backend, scheduling_method='alap')
backend.run(circuits, shots=NUM_SHOTS)

I tried a bunch of combinations and this was the only one that worked.

@CharlieDerby, thank you for noticing that and writing a great explanation!
Could you please submit a pr for that? Looks like @corbett5 also facing the same issue.

So this behavior is actually by design. The execute() function is not meant to expose every option of transpile() it's a higher level abstraction that is there primarily to provide a simpler experience for users that don't care about the internal operation of the transpiler and just want to take their circuits and run them on a backend. The options to the transpiler which are exposed via execute() are limited to just high level ones like optimization_level (there are options there which were added before we made this distinction clear which really should be deprecated and removed). If you're looking to control the scheduling of your circuits that's already a layer deeper than what execute() is intended for and calling transpile() directly is the intended path there.
I don't think this behavior of exeucte() is something we are going to change (we used to try and have execute() proxy everything in transpile() and assemble() a long time ago but that didn't scale and is why we made the separation of concerns clearer. However, I think we can make this distinction clearer in the documentation. So I'll leave this issue open and we can close it with a docstring update to explain the purpose of execute better.

@mtreinish How about raising an error for calls to execute with an unsupported transpile option, rather than ignoring it?

The problem there is we pass through all kwargs as run options to backend.run(). Since all backends have a unique set of runtime options they offer we made the decision a long time ago to pass kwargs to the backend.run() (or assemble() before BackendV1 and warn if an option is passed in the backend doesn't support but not ignore it: https://github.com/Qiskit/qiskit-terra/blob/main/qiskit/execute_function.py#L386-L396 (with the old pre-backendv1 approach no warning would be emitted the unsupported options were silently ignored by the backend).

In this case, scheduling_method is a correct parameter to execute, it's just gated behind passing schedule_circuit=True, and it's never passed to transpile, it's just used in the separate function schedule (a few lines below your change).  If you pass schedule_circuit=True as well, I think your example should work.
@yaelbh: it's a bit tricky to handle this, because execute collects up all its unknown keyword arguments to pass them to backend.run.

According to @mtreinish and @jakelishman's explanations, I'd expect the backend to warn about an unknown run option.

Ah I missed that, but it's bit weird because of the overloaded terminology. the schedule_circuit flag is to indicate that the circuit should be lowered to a pulse schedule prior to executing it. The scheduling_method arg there is for the schedule() not the transpile() call before it. These options actually predate the scheduler in the transpiler for scheduling gates. I feel like we should deprecate the support in execute() to schedule a circuit to a pulse schedule prior to calling run.

@mtreinish

If you're looking to control the scheduling of your circuits that's already a layer deeper than what execute() is intended for and calling transpile() directly is the intended path there.

In my example I attempted this method and got the same error. The transpiler outputs a circuit with (presumably) the correct extra delay to realign measurement but running that circuit leads to the same problem. I'm not sure why this is the case because it seems like the misalignment problem should be solved by pre-transpiling.

When you manually transpile something, are you then passing it to execute or to your backend.run?  After manual transpilation, you should do the latter, otherwise execute will re-transpile the circuit which will most likely invalidate its scheduling.  You should hopefully be able to do backend.run(transpiled_circuit, shots=10_000) without issue, which is the expected path for people who want finer-grained control over the transpilation process.
@yaelbh: that's a fair point.  At the moment, it looks like there is a notice emitted, but it's as a log message at level INFO, which isn't super visible.

@jakelishman that makes a good deal of sense, thanks.

Closing because:

The behavior is expected
There is a "workaround"
execute exists in 0.* series and it was removed in 1.*


text:
Relax opflow CODEOWNERS regex

Summary
This commit updates the CODEOWNERS regex for the opflow module. Previously it was set to opflow/ which will match any path with "opflow" as a directory in it. However, there are several documentation files that have opflow in the name. This commit updates the regex to just be the string "opflow" which will match any file or path that contains "opflow" so that the CODEOWNERS for opflow can merge PRs that touch this documentation too.
Details and comments

I pulled this from the merge queue, because this might not be general enough. It might be better to think about the docs/ ownership as a separate quantity (similar to releasenotes)

Pull Request Test Coverage Report for Build 6406397996

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.01%) to 87.017%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
93.76%

crates/qasm2/src/lex.rs
1
90.91%

qiskit/pulse/library/waveform.py
3
93.75%

Totals

Change from base Build 6398340617:
0.01%

Covered Lines:
74161

Relevant Lines:
85226

💛  - Coveralls

I was thinking that the whole opflow/algorithms thing will mostly resolve itself in a few weeks' time via their removal from the repo, so I wasn't particularly worried about those rules.  I agree that we'll probably need to re-examine ownership of docs and releasenotes to support more general cross-team stuff.

authors: coveralls jakelishman mtreinish


text:
Add support for stable versions of documentation

Summary
This commit adds support for hosting stable versions of the
documentation moving forward. This is accomplished by adding a new ci
workflow on tags that will upload docs to stable/$VERSION where $VERSION
is the first 2 components ('major.minor') from the version string. This
will let us maintain a hosted copy of each minor release of
documentation for users still running on older versions. The version
template and custom sphinx extensions are updated to determine the list
of versions from the current state of the git repo.
This PR assumes that we've manually updated 0.24.x, 0.25.x, and 0.26.x
to 'documentation/stable/0.24', 'documentation/stable/0.25', and
'documentation/stable/0.26' respectively. This is a blocker for merging
this because until that done the version menu will have broken links.
Details and comments

I've started uploading manually built version of documentation, https://qiskit.org/documentation/stable/0.25/index.html and https://qiskit.org/documentation/stable/0.24/index.html are up now (0.26 is being built right now). So we need to merge this sooner rather than later to ensure we don't accidentally delete those.

Thank you for merging this! Having old documentation helps a lot!

Thank you for this. Is it possible to move the versioned docs to a more visible location? Perhaps similar to how PyTorch hosts their versioned docs? https://pytorch.org/docs/stable/index.html

Thank you for this. Is it possible to move the versioned docs to a more visible location? Perhaps similar to how PyTorch hosts their versioned docs? https://pytorch.org/docs/stable/index.html

I'm not sure that I follow. Right now https://pytorch.org/docs/stable/index.html is roughly equivalent to https://qiskit.org/documentation/index.html, the main qiskit documentation page is for the latest stable release (in this case we're currently on 0.26.2). This PR added hosted copies for old stable releases such as https://qiskit.org/documentation/stable/0.24/index.html (which is equivalent to something like https://pytorch.org/docs/1.7.1/ in the pytorch docs). Are you asking to move documentation/stable/$version to documentation/$version or something else? If it's about how we expose the links to the old versions we're kind of stuck with how the qiskit_sphinx_theme package works right now, but we might be able to come up with something else. Can you open a new issue with the details of what you're looking for and we can discuss it in there.

Yes, it is about how we expose the links to the old versions. Currently, the links are buried in the language switcher drop-down and most people will not notice that the previous releases are there. I will open a new issue with details. Thanks.

authors: drewrisinger mtreinish veenaiyuri


text:
Create a standard sidebar structure in layout.html

The layout.html should have a standard structure that can be pulled in by all qiskit repos.
Current plan:
[language dropdown]

[search box]

Qiskit {Repo Name} Documentation
   Overview
   Getting Started
   Tutorials
   How to Guides
   API Reference
   FAQs
   Release Notes
   GitHub

[previous releases list]

Open questions for discussion:

Should we require every page listed above or just some or none?
Which pages should we insist be there and which should be optional?
Should we allow individual repos to add their own links to the sidebar list?

cc: @HuangJunye @agebbie

Updated standard structure from discussion today:
# Standard - Must haves
Overview
Getting Started (installation + hello world + link to tutorials)
Tutorials
How-to Guides
API Reference
Explanations
Release Notes
GitHub

# Standard - recommended but not mandatory
Previous Releases

# Optional Extras
blank box we can fill with optionals e.g.:
FAQs


text:
relation::transforms::tests::test_compute_norm_for_join is failing for some seeds

As seen in: https://github.com/Qrlew/qrlew/actions/runs/5204906618/jobs/9389729846
Query = WITH join_gyct (field_0eqn, field_3ned, field_gwco, field_eygr, field_0wjz, field_cg0j, field_idxm) AS (SELECT * FROM item_table JOIN order_table ON item_table.order_id = order_table.id), map_z3vu (field_58dd, field_iee9, field_x5m5, field_wbdh) AS (SELECT field_gwco AS field_58dd, field_0wjz AS field_iee9, field_3ned AS field_x5m5, field_idxm AS field_wbdh FROM join_gyct), reduce_2ci9 (field_0wjz, field_3ned, field_idxm, field_m1mi) AS (SELECT field_iee9 AS field_0wjz, field_x5m5 AS field_3ned, field_wbdh AS field_idxm, sum(field_58dd) AS field_m1mi FROM map_z3vu GROUP BY field_iee9, field_x5m5, field_wbdh), map__oah (field_e700, field_x5m5, field_wbdh) AS (SELECT abs(field_m1mi) AS field_e700, field_3ned AS field_x5m5, field_idxm AS field_wbdh FROM reduce_2ci9), reduce_kvk7 (field_3ned, field_idxm, field_b_y3) AS (SELECT field_x5m5 AS field_3ned, field_wbdh AS field_idxm, sum(field_e700) AS field_b_y3 FROM map__oah GROUP BY field_x5m5, field_wbdh) SELECT * FROM reduce_kvk7
thread 'relation::transforms::tests::test_compute_norm_for_join' panicked at 'assertion failed: `(left == right)`

I tested 16 different seeds and it worked fine... 🤔

repo: Qrlew/qrlew


text:
JuliaBox Requirements

cc @jlperla
They've overhauled the Julia setup over the break (i.e., now it's Julia 1.0.3), so a priori none of the old information is valid.
Things we need but can't fix

InstantiateFromURL - can't install any version after v0.1.0 (i.e., no error handling that prevents a crash/tells people to add stuff manually).
I can't get RDatasets to work, even though it looks like it installs properly. Same with the REPL required for ] build NodeJS, which is required for VegaLite and DataVoyager.
FastGaussQuadrature isn't in the registry, and we need it for the general_packages lecture.

Things we need and can fix (with workarounds)

] add Expectations
] add StatPlots
] add DataFramesMeta CategoricalArrays Query GLM RegressionTables FixedEffectModels
] add QuadGK Interpolations LaTeXStrings ProgressMeter
] add JuMP Ipopt BlackBoxOptim
] build Ipopt
] add LeastSquaresOptim

Lectures I tested:

McCall
Wald-Friedman
Data and Statistical Packages
General Packages
Kalman
Lake Model
Lucas Model
Solvers, Optimizers, and Automatic Differentiation

Closing as we're done testing this for the time being. Can re-open if we start again.

I want to reopen until this is either dealt with or ignored. We can assign to me

authors: arnavs jlperla

repo: QuantEcon/lecture-source-jl


text:
ExcelPainter: "italic" is added to format_name twice

... under certain conditions. There should be a check on format_name so it isn't added twice.

Resolved by #481.

authors: AlasdairE jamesrkg

repo: Quantipy/quantipy


text:
Add openjdk 16

New JDK version added. I also gave the README a refresh pass. I also snuck in a small enhancement that pulls upstream images before building on them. I noticed that sometimes builds would be different on my local machine if I had an outdated upstream openjdk image already cached. This helps ensure (but does not guarantee) that my local builds are the same as what will get built on the Docker image infrastructure.
After this I'm going to work on reverting our tools-deps images to stable releases only, which I recently learned were a thing: https://groups.google.com/u/2/g/clojure/c/cS8KjpTKBl0

Official library PR: https://github.com/docker-library/official-images/pull/8558

repo: Quantisan/docker-clojure


text:
Trivial level solutions

From a discussion at the Explorable Explanations Slack:

15 - easy to fix. Regarding the first screenshot, we would need to change the detector element to only receive photons on one side.
Re other comments from the Explorable Explanations Slack user, I think highlighting the ket viewer and its options, rendered photon on hover in the hints section - that would all help understand what is happening with the photon on the board. Although I am not sure if we can (or should) do anything with this right now.
Also - at a later stage - changing the photon itself, the rendering can be improved.

One thread per issue at a time.
Detecting the direction of the beam would need some changes (these are on the way in quantum-tensors, as a part of more general measurement).
Also: do you have an idea of how to show a plant with light coming from a different angle?

Not sure if I understand what do you mean by showing a plant with light coming from a different angle. The photon getting to the plant from other direction than the mouth? I would leave it green, not affected, or with an outline only, but not "energized". Something like a mirror or beamsplitter absorbing the photon when placed not diagonally.

Currently we don't check for the direction of the photon to trigger the detection event. So the normal detector acts as a 4-way detector. This change has to be made in quantum-tensors elements.

authors: KlemKlem sneakyweasel stared


text:
Bump Makie compat

If you want to submit an unfinished piece of work in order to get comments and discuss, please mark the pull request as a draft and ping the repository maintainer
Before considering your pull request ready for review and merging make sure that all of the below are completed:

The code is properly formatted and commented.
Substantial new functionality is documented within the docs.
All new functionality is tested.
All changes and new functionality are marked in the CHANGELOG file.

Thanks for the submission! It does not seem Makie 0.21 is released yet, so I can not rely on the tests passes here to be correct. I will close this for now (the Compat Helper bot will resubmit this when Makie 0.21 is released).


text:
QuickBlox error

Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: [QMCore instance].currentProfile.userData'

closed as https://github.com/QuickBlox/q-municate-ios/issues/213

authors: VitaliyGuru videhjaiswal

repo: QuickBlox/q-municate-ios


text:
quicklogic: add toolchain install test

This PR fixes https://github.com/QuickLogic-Corp/symbiflow-arch-defs/issues/270.
It adds a test to verify that the installed toolchain is not erroring out, and is properly working.

@acomodi : so any new testcase if i need to add, i should also add in the build.yml ?

@kkumar23 So, if you want to use the same design and the same device you may enhance the Makefile in the install_test directory. This can be done in case more features need to be tested.
In general, though, the toolchain installation checks should only regard the feature testing (e.g. liberty file generation, post synthesis checks, etc.). In case a new design needs to be tested, it is better to add it to the test suite as all the other tests.

json file is not required now, as the support for the clk's is now present in the pcf file.

Ok, I have removed it

repo: QuickLogic-Corp/symbiflow-arch-defs

license: ISC


text:
Line Widths Don't Scale

When canvas size or board size are changed to extreme values, visual issues occur. Line widths are hard coded values, but should be calculated based on both canvas size and board size.

Bug Resolved

repo: QuixoticLeprechauns/jul-gonu


text:
🛑 Broker is down

In 478876a, Broker (https://broker.autovance.com/health) was down:

HTTP code: 503
Response time: 346 ms

Resolved: Broker is back up in a162fcd.

repo: QuorumDMS/av-uptime


text:
Fix cmds with no parameters

EVerest is sending null as parameter for commands that do not take any parameter. However the Rust code is expecting HashMap<String, Value>. Fix this problem by deserializing into an Option and if it is None pass on an empty HashMap.
Also:

Add debug logging for received JSON

looks good but - but don't we have to handle also the () types for the generated function signatures? anyhow we can tackle it in a different pr. Run cargo metadata to fix the bazel pipeline

authors: SirVer dorezyuk

repo: Qwello/everest-framework


text:
[BUG]

是否已有关于该错误的issue或讨论？ | Is there an existing issue / discussion for this?

[X] 我已经搜索过已有的issues和讨论 | I have searched the existing issues / discussions

该问题是否在FAQ中有解答？ | Is there an existing answer for this in FAQ?

[X] 我已经搜索过FAQ | I have searched FAQ

当前行为 | Current Behavior
Traceback (most recent call last):
File "/root/autodl-tmp/Qwen/finetune.py", line 374, in
train()
File "/root/autodl-tmp/Qwen/finetune.py", line 363, in train
trainer = Trainer(
File "/root/miniconda3/envs/qwen/lib/python3.10/site-packages/transformers/trainer.py", line 340, in init
self.create_accelerator_and_postprocess()
File "/root/miniconda3/envs/qwen/lib/python3.10/site-packages/transformers/trainer.py", line 3883, in create_accelerator_and_postprocess
self.accelerator = Accelerator(
TypeError: Accelerator.init() got an unexpected keyword argument 'dispatch_batches'
运行环境 | Environment
- OS: linux
- Python: 3.10
- Transformers: 4.32.0
- PyTorch: 2.1.0
- CUDA (`python -c 'import torch; print(torch.version.cuda)'`):12.1

备注 | Anything else?
No response

我也有这个错误

repo: QwenLM/Qwen


text:
[📖]Image Optimization Misguide

Suggestion
Visit Image Optimization section and you'll encounter this code:
import Image from '[IMAGE_PATH]??w=24&h=24&jsx';

which actually doesn't work due to double question marks instead of single:
import Image from '[IMAGE_PATH]?w=24&h=24&jsx';

I would also like to suggest adding a notice to denote what some things mean, especially to fresh beginners like what the square brackets in the above code denotes to make it easier to understand as well as fix these minor issues.

#7073 fixed the double ? issue

authors: binmalyi gioboa

repo: QwikDev/qwik


text:
x-auth header

set x-auth header instead of in body of request

We can do this using httr2::req_auth_bearer_token()
https://httr2.r-lib.org/reference/req_auth_bearer_token.html

repo: R-ArcGIS/arcgislayers


text:
organizing markdown files

I like having the .md file in the repository because it renders as the final version within Github. It seems useful to include the .Rmd files though so that you can edit in RStudio (you need this file, right?). Do we include both? Put them in separate folders?

Included instructions in the Readme

repo: R-Ladies-Gainesville/tutorials