yt-project / yt Goto Github PK
View Code? Open in Web Editor NEWMain yt repository
Home Page: http://yt-project.org
License: Other
Main yt repository
Home Page: http://yt-project.org
License: Other
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Summary: EnzoDerivedFields is highly unflexible
Component: lagos
Milestone: 1.0
Reporter: mturk
Owner: mturk
**Resolution: fixed
Status: closed
Created: 1184383465000000
Description: EnzoDerivedFields needs to be rewritten from an OO standpoint.
Set up some basic class system, accepting function calls as arguments, and then query the class for more information.
Rework GenerateField to allow for more information.
Include both initialization and clean-up routines, so that memory usage can be reduced, and thus allow for fallback without doubling-tripling-etc memory needs.
=== Update to Ticket ===
Do we also want to create a class for holding all of the data? Right now, it's all stored in dictionaries. Maybe this is unwise -- if we had a special class, we could call dataContainer.cleanUp() and have it wipe out all of the fields not explicitly requested.
=== Update to Ticket ===
Also, something needs to be done about the namespace pollution that goes on with EnzoDerivedFields. I don't think we need to import any more than fieldInfo.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
We define a function (not a decorator) to process each of the functions, and hand it over to fieldInfo. (We will for now simply include inside fieldInfo a Field object, which will issue deprecation warnings whenever [0],[1],etc are called.)
This object will address the following issues:
Additionally, we should have fieldInfo be a subclass of dict, which will process all the appropriate calls to the field, and taking care of thigns like _Abs and _Squared and the various vector components.
=== Update to Ticket ===
Additionally, CGS is enforced everywhere. Conversion to other units is a very simple exercise, because we no longer store unnecessary fields.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Here are a couple ideas I have for how to do this.
Via IPython
Via Forking (for SMP)
Via Threading
Via NetWorkSpaces
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
So the obvious first starting point is to pull out all of the hierarchy queries inside the projection class, and put corresponding information back into the GridCollection object, or, even better, into the Enzo3DData object. Then we'll simply transform EnzoProjection from working on a hierarchy to working on a collection of objects, and as long as the data protocol works identically, we'll have all the information we need to project small quantities of data.
So we could dispatch decomposed portions of the dataset to different processors, and then have a collection at the end of each stage on the head node. (Or even some kind of round-robin collection, although perhaps a binary-collapse would be best.)
Note that we can retain the full-domain projection by having hierarchies export the same data that a grid collection would, or even by creating an empty grid collection for every projection. (Make hierarchy.slice into a method rather than a class instantiation.)
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Author: mturk
Changetime: 1218210142000000
Field: comment
Oldvalue: 9
Newvalue: Okay, something like the following:
#!python
cc = MPI.Compute_dims(MPI.WORLD_SIZE, 2)
mi = MPI.WORLD_RANK
cx, cy = na.unravel_index(mi, cc)
x = na.mgrid[0:1:(cc[0]+1)*1j][cx:cx+2]
y = na.mgrid[0:1:(cc[1]+1)*1j][cy:cy+2]
LE = na.array([0.0, x[0], y[0]])
RE = na.array([1.0, x[1], y[1]])
reg = pf.h.region((RE-LE)/2.0, LE, RE)
but not necessarily identical to that would work inside the projection initializer. Then we'd want to call a finalizer, which maybe we should be doing anyway, and then use that to scatter the arrays back.
This should preserve the adaptive nature of the projections. Fixed-resolution projections work as is in the parallel profiles.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
~/.yt/custom_fields.py
and have those fields then be available to him inside his session.
If we ignore the possibility of malicious code, this would be simple. Do we want to do that?
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
This can be done via SAGE, which would really just be an extension of what already exists, via wxAgg/wxPython, via Envisage, or something else.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
The following goals have to be met:
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Look into using the NumPy lazy importer. (Tried another lazy importer before, but no dice.)
Perhaps a config flag for which modules not to import -- both tables and pyhdf_np are rather slow.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Packaging sample data in acceptable way. (I have a dataset picked out; it is small enough to be easy to pass around -- 60mb or so -- but big enough to showcase some issues.)
Deciding on an appropriate way to test more advanced derived quantities. Radial profiles could be easy; some kind of checksum on the data, and projections similarly so, but the issue comes in with the plotting packages.
Writing unit tests.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
This involves stripping out all the unnecessary configuration information, and then moving API keys into the DB.
Additionally, move some of the welcome-screen stuff into the configuration file. (Find out how to reference those vars inside the templates?)
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Passing in spheres is now accessible, as well, so that is also done.
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
I believe the best way forward is to abstract the fields from the data. Call a function to initialize a new field, rather than simply adding it to lagos.fieldInfo -- that way a more sane default-generator can be used, and things like LaTeX representations can be used as appropriate.
This will break stuff, but I believe the only person using their own derived fields is Fen.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
This will require a substantial change to the API; it won't be suitable for the 0.2 release. 0.3 is where this should go, and it will require changing most of the examples and wiki entries.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
I have not converted the arrays yet. Those will be conveted to descriptors, so that the axis-specific stuff can be generated on the fly.
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Copying the ActiveDimensions into a separate array should be avoided, but may be difficult to avoid. Maybe a two-step process - one for the inner region, where the stencil doesn't need ghostzones, and then a set of operations for each face, including GZs?
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
However, it is part of a larger rewrite. I am leaving this open, but noting the change here. (I will close when it is committed and works.)
The method used is to create a dupe DataCube that includes the ghost zones, grabbed from the surrounding grids.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
The reasons for doing this are two-fold --
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Assuming we have a version 1.0 release, I do not foresee HDF4 being supported past 1.0. So this ticket may ultimately be resolved as "dontfix."
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
na
'''and''' obj
? this is very confusing, especially for new users. in lagos, references to nT
, na
, and obj
are scattered throughout. i assume this was to support some kind of easy switching between numpy and numarray, but it seems to me that the days of support for both are past. if we eliminate any trace of numarray, will nT still be necessary?given Matt's comment in the header of arraytypes.py
, perhaps this should be re-factored sooner rather than later?
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Author: joishi
Changetime: 1197051576000000
Field: comment
Oldvalue: 2
Newvalue: i did a quick grep for "obj\." in the yt src tree. doesn't look like there are too many places to replace it if we want to.
[joishi@skronk src]$ ls
init.py config.py enki funcs.py logger.py raven setup.py
arraytypes.py deliverator fido lagos progressbar.py reason setup.pyc
[joishi@skronk src]$ grep "obj\." */*py
lagos/EnzoRunType.py: self.outputs = obj.array(outputs) # Object array of EnzoHierarchies
lagos/EnzoRunType.py: self.outputs = obj.array(self.outputs.tolist() + hierarchy)
lagos/EnzoRunType.py: newOutputs = obj.array(self.outputs[:id].tolist() + self.outputs[id+1:].tolist())
lagos/EnzoRunType.py: newTimesteps = obj.array(self.timesteps[:id].tolist() + self.timesteps[id+1:].tolist())
lagos/HierarchyType.py: self.grids = obj.array([self.grid(i+1) for i in xrange(self.numGrids)])
[joishi@skronk src]$ grep "obj\." //py
deliverator/deliverator/json.py:# return [obj.val1, obj.val2]
deliverator/deliverator/json.py: result["users"] = [u.user_name for u in obj.users]
deliverator/deliverator/json.py: result["permissions"] = [p.permission_name for p in obj.permissions]
deliverator/deliverator/json.py: result["groups"] = [g.group_name for g in obj.groups]
deliverator/deliverator/json.py: result["permissions"] = [p.permission_name for p in obj.permissions]
deliverator/deliverator/json.py: result["groups"] = [g.group_name for g in obj.groups]
[joishi@skronk src]$ grep "obj\." ///*py
deliverator/deliverator/tests/test_model.py:# assert obj.display_name == "Mr Creosote"
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
The unstable branch will be moved over to the trunk early next week, since I have tagged release-0.2.1.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
The best way to get around this, it seems, is to deal properly with lower-precision runs. r8 should be stable, because we do things with 64-bit precision, but r4 is not.
I'm filing this under raven for now, but it may be more of a lagos problem. The current solution is to crop out the bad (i.e. <=0) values, and then normalize the remaining ones.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
I've tried reconstructing the original and correct gridLeftEdge and gridRightEdge values by dividing by dx, taking the rint(), and then multiplying again by dx, but that did not work. Additionally, I'm not sure that reconstructing the entire hierarchy is necessarily wise.
As a note, I found that the discrepancy between the "modified" gLE&gRE values and the original ones was up to 40% of the dx of the finest level (level 8.)
I'm not entirely sure this is actually a real problem specific to yt, specific to python, or just overrunning the precision of the hierarchy file in r4.
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Summary: Reason functionality
Component: reason
Milestone: 0.2
Reporter: mturk
Owner: mturk
**Resolution: duplicate
Status: closed
Created: 1186070496000000
Description: Reason needs to have the following things implemented:
Setting limits
Clicking to change center
Progress bars (will require change in yt.progressbar)
About box with license
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Author: mturk
Changetime: 1184212388000000
Field: comment
Oldvalue: 2
Newvalue: Callbacks have been added. Now when you add a VMPlot in MPL, you can add a callback function. Two example callback functions have been added. Only one can be used at a time. Here is an example:
pc.addSlice("NumberDensity", 0, center=c, coord=c[0])
pc.plots[-1].setCallback(raven.be.contourCallback("Temperature",0))
or:
pc.addSlice("MachNumber", 0, center=c, coord=c[0])
pc.plots[-1].setCallback(raven.be.quiverCallback("y-velocity","z-velocity",0,32))
Note that the last arg in the contourCallback is the axis, and then in the quiverCallback the last number is the "skip" parameter.
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
in VMPlot, redraw_image()
runs self.autoset_label()
, but does not define it, nor is it inherited from RavenPlot. It is defined in all functions that derive from VMPlot, but if one were to write a new class and forgot it, it would error.
the fix would be to do
def autoset_label()
pass
in VMPlot. i suppose this is trivial, but it could be a headache later.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
I am temporarily bumping this to 0.3. It may come back during the bug-testing cycle.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Summary: Licensing situation is unclear
Component: documentation
Milestone: 0.2
Reporter: mturk
Owner: mturk
**Resolution: fixed
Status: closed
Created: 1185653877000000
Description: yt has been cleared to be released as a GPL'd program. It's time to move on this.
Read the GPL FAQ and howto
Add license to top of each software component
Add license to archive
Submit to CheeseShop
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
Summary: Get rid of some extensions
Component: yt
Milestone: 1.0
Reporter: mturk
Owner: mturk
**Resolution: fixed
Status: closed
Created: 1189204290000000
Description: There are a couple C extensions in the codebase:
combination of projected points within a level
combination of projected points across a level
binning of values for radial profiles
interpolation for rates
pixelization for plotting in matplotlib
I believe that only the binning should be moved. The interpolation needs to stay, as the appropriate method of moving it would be to instead utilize a scipy package, but we actually want to stay as close to enzo as possible. Any other interpolation needs that do not need to replicate code can be moved to scipy or weave. Pixelization should be kept the same, as there are multiple entry points. Projection could be moved, which would open us up to easier creation of MIP projections, but that is not something to be taken lightly -- we could do this via string substitution, which would work great, but then we open ourselves up to unnecessary recompilation in weave, depending on how the checksums are calculated.
So for now, we move just the binning to weave.inline.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
by commenting out the type_converters=converters.blitz line and modifying WeaveStrings.py to use standard C/C++ array syntax, it will compile. however, it then returns a properly sized array of zeros. i am investigating this further, but i know nothing about weave/blitz.
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)
== Imported Ticket ==
=== Update to Ticket ===
=== Update to Ticket ===
=== Update to Ticket ===
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.