profile
viewpoint
Andreas Madsen AndreasMadsen Computationally Demanding Copenhagen, Denmark https://andreasmadsen.github.io/

AndreasMadsen/clarify 123

Remove nodecore related stack trace noise

alexgorbatchev/node-browser-builtins 58

Browser altenatives to built-in node.js modules

AndreasMadsen/async-hook 33

Inspect the life of handle objects in node

AndreasMadsen/distributions 30

A collection of probability distribution functions

AndreasMadsen/article 28

Analyze a stream of HTML and outputs the article title, text, and image

AndreasMadsen/course-02456-sparsemax 14

TensorFlow and Numpy implementation of sparsemax

AndreasMadsen/dgram-emitter 12

Very simple EventEmitter on top of a UDP server/client

AndreasMadsen/configme 4

Simplest possible configuration tool. without conflict - with defaulting!

AndreasMadsen/cahier 3

static file conversion, writing and reading

AndreasMadsen/course-42137 2

Optimization using metaheuristics - University Timetabling

issue commentAndreasMadsen/python-textualheatmap

Is it possible to do it with phrases?

Yes. Just make the tokens contain spaces. There are already examples with both character level and word level, so the API is abnostic.

zanderbush

comment created time in 3 days

issue closedadmazely/inspector

cant install- loads of node errors

I get a crazy list of node errors when I try and install this. I'm using:

npm 6.11.3 node v11.13.0

I've tested with just inspector, here is the package.json:

{
  "name": "app",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "inspector": "0.5.0"
  }
}

Here is a sample of the errors, I will not copy it all:

Andrews-MBP:RealityCardsFrontEnd mcplums$ npm install

> bufferutil@1.1.0 install /Users/mcplums/Repos/RealityCardsFrontEnd/node_modules/bufferutil
> node-gyp rebuild

  CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
In file included from ../src/bufferutil.cc:16:
In file included from ../node_modules/nan/nan.h:82:
../node_modules/nan/nan_new.h:29:56: warning: 'ToInteger' is deprecated: Use maybe version [-Wdeprecated-declarations]
To<v8::Integer>(v8::Handle<v8::Integer> i) { return i->ToInteger(); }
                                                       ^
/Users/mcplums/Library/Caches/node-gyp/11.13.0/include/node/v8.h:2550:10: note: 'ToInteger' has been explicitly marked deprecated here
  inline V8_DEPRECATED("Use maybe version",
         ^
/Users/mcplums/Library/Caches/node-gyp/11.13.0/include/node/v8config.h:326:29: note: expanded from macro 'V8_DEPRECATED'
  declarator __attribute__((deprecated(message)))
                            ^
In file included from ../src/bufferutil.cc:16:
In file included from ../node_modules/nan/nan.h:82:
../node_modules/nan/nan_new.h:34:56: error: no matching member function for call to 'ToInt32'
To<v8::Int32>(v8::Handle<v8::Integer> i)   { return i->ToInt32(); }
                                                    ~~~^~~~~~~
/Users/mcplums/Library/Caches/node-gyp/11.13.0/include/node/v8.h:2531:43: note: candidate function not viable: requires single argument 'context', but no arguments were provided
  V8_WARN_UNUSED_RESULT MaybeLocal<Int32> ToInt32(Local<Context> context) const;
                                          ^
/Users/mcplums/Library/Caches/node-gyp/11.13.0/include/node/v8.h:2544:30: note: candidate function not viable: requires single argument 'isolate', but no arguments were provided
                Local<Int32> ToInt32(Isolate* isolate) const);
                             ^
In file included from ../src/bufferutil.cc:16:
In file included from ../node_modules/nan/nan.h:82:
../node_modules/nan/nan_new.h:39:65: error: too few arguments to function call, single argument 'context' was not specified
To<v8::Uint32>(v8::Handle<v8::Integer> i)  { return i->ToUint32(); }
                                                    ~~~~~~~~~~~ ^
/Users/mcplums/Library/Caches/node-gyp/11.13.0/include/node/v8.h:2529:3: note: 'ToUint32' declared here
  V8_WARN_UNUSED_RESULT MaybeLocal<Uint32> ToUint32(
  ^
/Users/mcplums/Library/Caches/node-gyp/11.13.0/include/node/v8config.h:418:31: note: expanded from macro 'V8_WARN_UNUSED_RESULT'
#define V8_WARN_UNUSED_RESULT __attribute__((warn_unused_result))
                              ^
In file included from ../src/bufferutil.cc:16:
In file included from ../node_modules/nan/nan.h:82:
In file included from ../node_modules/nan/nan_new.h:189:
../node_modules/nan/nan_implementation_12_inl.h:49:38: error: too few arguments to function call, expected 2, have 1

Wat do?

closed time in 11 days

mcplums

issue commentadmazely/inspector

cant install- loads of node errors

I would suggest using https://github.com/puppeteer/puppeteer instead. If I remember correctly puppeteer is partially maintained by the chromium team, so it will stay up to date.

This module is very old, and no longer actively maintained.

mcplums

comment created time in 11 days

issue commentAndreasMadsen/python-lrcurve

Plotting broken in TensorFlow 2.2

This fix do have the downside that the plot isn't rendered until the end of the first epoch.

DJCordhose

comment created time in 14 days

issue closedAndreasMadsen/python-lrcurve

Plotting broken in TensorFlow 2.2

TF 2.2 changed its API so that metrics_names are only available after the model has been trained/evaluated on actual data.

the on_train_begin callback tries to use that information, but since it is the beginning of the training, those metrics are not there, yet.

this is the error you will get

<ipython-input-18-782c326bcb7b> in on_train_begin(self, logs)
     55         if self._metric_mapping is None:
     56             self._metric_mapping = {}
---> 57             for metric_name in self.params['metrics']:
     58                 if self.params['do_validation'] and metric_name.startswith('val_'):
     59                     self._metric_mapping[metric_name] = {

KeyError: 'metrics'

closed time in 14 days

DJCordhose

issue commentAndreasMadsen/python-lrcurve

Plotting broken in TensorFlow 2.2

Should be fixed now in version 1.1.1.

DJCordhose

comment created time in 14 days

push eventAndreasMadsen/python-lrcurve

Andreas Madsen

commit sha c97ac449b0b2c42d4ae3b7a1993c658081f53c67

tensorflow 2.2.0 compatability

view details

Andreas Madsen

commit sha d8d70ead637fc7b9d5b3022302d6c7a427b5c74a

version 1.1.1

view details

push time in 15 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

@puzpuzpuz Alright, I wrote my proposal as its own issue. See: https://github.com/nodejs/diagnostics/issues/389

Qard

comment created time in 16 days

issue openednodejs/diagnostics

Proposal for reworking promise integration into async_hooks

Background

The current implementation of promise integration into async_hooks is.

  1. For each new [[Promise]] object, call the init hook with a PromiseWrap referencing that Promise.
  2. At resolve or reject call the resolve hook.
  3. For each [[then]] callback, call the before hook before calling the callback.
  4. For each [[then]] callback, call the after hook after calling the callback.
  5. When the Promise object is garbage collected call the destroy hook.

I think this implementation is fundamentally wrong, as it intertwines the promise lifecycle with async_hooks. This causes a number of issues that are currently blocking us from making async_hooks stable.

  • Performance issues caused by listening for the garbage collection event.
  • Thenables are not tracked when used by a native function that creates a microtrask.
  • destroy hook is not called if async_hook is enabled after Promise creation.
  • Tracking the async boundary when multiple .then() are used is not possible.

Proposal

My proposal is to rework the promise integration into async_hooks such that the async barrier is around the [[then]] call, not creating a new Promise object.

  1. at the call of [[then]] on a promise or thenable create a resource object (or use the promise/thenable object created by [[then]]) then call the init hook.
  2. at the call of the[[then]] callback, the before hook is called.
  3. at the end of the[[then]] callback call the after hook, immediately after call the destroy hook.

How it solves the above-mentioned issues

Performance issues caused by listening for the garbage collection event.

Because the before and after hooks are only called once per resource, the destroy hook can be called immediately after the after hook. Thus completely eliminating the need to track promise objects in the garbage collector.

Thenables are not tracked when used by a native function that creates a microtrask.

This can now be solved because we don't need to know when the object was created or destroyed. The only knowledge that is required is when [[then]] method of the thenable is called by the native JS APIs that invokes the microtask queue. That is actually doable, as we could potentially hook into those APIs. Only manual calls to [[then]] on a thenable will not be tracked. But I don't see that as a concern, because that is not an async action.

destroy hook is not called if async_hook is enabled after Promise creation.

Again, because the destroy hook is called with the after hook, calling the destroy becomes trivial.

Tracking the async boundary when multiple .then() are used is not possible.

This directly confronts this issue, by making the async boundary the [[then]] call.

Tracking the lifetime of promises

This proposal removes features from async_hooks that provide insight into promises. That information is still valuable.

To keep providing that information, I propose making a dedicated promise_hooks module. A user can then connect the promise lifecycle with async_hooks via a promiseId that is exposed both in promise_hook and via the resource in async_hooks.

Compatability

This does change the default async stack, as the start point of the async-barrier is now the .then() call and not the new Promise call. However, I think this is actually a preferred default. For example, lazyloading a resource with new Promise, would currently not be tracked correctly, but with the proposed change it will.

Even though this changes the async graph, the proposed async graph will still be valid and useful in most cases. And the existing async graph can be restored by integrating the proposed promise_hooks module.

Open questions

  • [ ] It is unclear to me how this would integrate with async/await. As I don't have a good grasp of how the internal [[then]] calls are used and wrapped. It has been proposed that we supply our own custom MicrotaskQueue (https://github.com/nodejs/diagnostics/issues/376#issuecomment-623682088) to solve this. I think this could also be a good approach to hook into the native promise APIs, which will be necessary to track [[then]] calls on thenables.

created time in 16 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

With the proposed behavior in promise integration, the original snippet (the one with a promise) will produce incorrect results. Luckily, it may be fixed by having a separate resource object per then invocation. That's just something that should be kept in mind when implementing your proposal.

Great. Please don't assume anymore that I intended to call the [[init]] multiple times on the same resource. That was never the case and it leads to a strawman discussion that is a waste of time.

I have clarified in the initial proposal that a new resource object should be created, or alternatively the returned the Promise by [[then]] is used.

Qard

comment created time in 16 days

issue commentAndreasMadsen/python-lrcurve

Plotting broken in TensorFlow 2.2

Yeah, I found the same issue. It might be a bug in kreas. I will investigate some more.

DJCordhose

comment created time in 17 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

What makes you think it's a mem leak? In fact ALS is more memory safe than destroy-based CLS implementations, as it relies on GC of async resources.

I could be wrong. That is anyway a separate discussion.

I've just tried running this snippet on node 14.2.0 and got 1 and 2 printed in console, which is the expected behavior. That happens because each process.nextTick invocation is tracked as a separate async resource, so propagation works correctly in this code.

That is great. If it works with process.nextTick it will work with .then. My proposed change makes behave the same.

Qard

comment created time in 17 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

The above snippet assumes current implementation of AsyncLocalStorage and the proposed Promise + async_hooks integration. It's a bit synthetic and, yes, the current code base may also lead to weird behavior in edge cases (yet, they're different). But my point is that a single property in combination with the proposed behavior may lead to certain problems and it should be improved somehow during the change.

This is a problem with AsyncLocalStorage. I was not here for when it was made, so I don't know the background for why it was designed the way it is. As far as I can see, .run() introduces a memory leak, which is also what leads to the bug you mention.

In any case, the issue you describe is no different if process.nextTick was used. Therefore, it has nothing to do with my proposed change to Promise integration in aynnc_hooks.

const als = new AsyncLocalStorage();

als.run(1, () => {
  process.nextTick(() => { // store 1 gets propagated here
    console.log(als.getStore()); // 2 - Incorrect, should be 1
  });
  als.run(2, () => {
    process.nextTick(() => {  // store 2 gets propagated here and overwrites store 1
      console.log(als.getStore()); // 2 - Correct
    });
  });
});
Qard

comment created time in 17 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

Sounds like a change that could be shipped in the next major release.

Yes, this would be a breaking change. So definitely for next major release.

The only potential problem that I can foresee is the fact that AsyncLocalStorage currently stores the context in a symbol property of the promise wrap (or the promise itself, if we consider #32891). With the proposed change a single promise may stand for multiple async resources, yet the context is stored in a single place. Maybe we could fix that with a wrap per each then invocation, but it may lead to races because of the asynchronous execution of the callback. WDYT?

I don't really understand. There will still be an object to attach properties too, you could even make it the promise object returned by .then(). The callbacks will be executed in the order they are queued, no difference there. It is also possible that using object properties will be less necessary since this would meditate a lot of the performance issues with destroy.

Qard

comment created time in 18 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

We would need a way to be able to capture and wrap the context for each microtask for it to run as within the queue. Perhaps we could supply our own custom MicrotaskQueue?

Makes sense. I think that would also be a good approach for hooking into the native Promise APIs to support thenables.

Qard

comment created time in 22 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

Considering this, do you propose to assign a unique async id to each invocation of then?

Yes. Each then is its own async resource, with its own async id. A Promise object is not the actual async boundary, and therefore not what should be tracked by async_hooks. The async boundary is the microtrask caused by .then().

Don't get me wrong. I'm all for simplifying things, but we need to avoid breaking existing code, at least without a really strong reason. Maybe it makes sense to introduce promise_hooks as a separate experimental module and keep async_hooks as they are now? The new module could rethink async_hooks lifecycle: it could remove destroy hook, for instance.

I think we do need to break the existing code. As I see it there are 3 issues with promises:

  1. destroy hook is not called if async_hook is enabled after Promise creation.
  2. Performance issues caused by listening for the garbage collection event.
  3. Thenables are not tracked when used by a native function that creates a microtrask.

I don't think any of these issues can be solved given the current specifications around Promises.

This will be a problem if a new context scope is started in the middle of the chain. In essence, we loose information about the async chain here, as the correct chain is root -> A -> B -> C.

  1. I disagree that the "correct chain" is root -> A -> B -> C. I think there are multiple correct chains. This is also discussed in the old Microsoft paper on the subject.

  2. I just want to point out that the current default context is not root -> A -> B -> C:

const { AsyncLocalStorage } = require('async_hooks');
const cls = new AsyncLocalStorage();

cls.run({ s: ['root'] }, function () {
    Promise.resolve(1)
        .then((v) => cls.run({ s: [...cls.getStore().s, 'A'] },
                             () => console.log(cls.getStore().s)))
        .then((v) => cls.run({ s: [...cls.getStore().s, 'B'] },
                             () => console.log(cls.getStore().s)))
        .then((v) => cls.run({ s: [...cls.getStore().s, 'C'] },
                             () => console.log(cls.getStore().s)))
});

prints [ 'root', 'A' ], [ 'root', 'B' ], [ 'root', 'C' ]. And not [ 'root', 'A' ], [ 'root', 'A', 'B' ], [ 'root', 'A', 'B', 'C' ].

  1. root -> A -> B -> C would be an optional context path that can be implemented given the right promise_hooks API.

Maybe it makes sense to introduce promise_hooks as a separate experimental module and keep async_hooks as they are now? The new module could rethink async_hooks lifecycle: it could remove destroy hook, for instance.

No, that would just make a bad situation worse. async_hooks is already mixed with promise specific semantics, such as resolve. Mixing promise_hooks with async_hooks just makes things worse.

Qard

comment created time in 22 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

at the call of [[then]] in a promise or thenable, the init hook is called. What happens if a user-land module calls new Promise() in one async context, but the resolve happens in another one (say, some operation queuing is happening)? With the proposed change AsyncLocalStorage (and, probably, user-land CLS libraries) may loose context.

They will not lose context, they will have a different context. If that context is unsatisfying, one should integrate with promise_hooks. But I think in most cases it is satisfying.

at the end of the[[then]] callback, the after hook is called followed by the destroy hook. This may be too early to emit destroy here as at this point init emit didn't happen for the chained promise, if any. I have a feeling that destroy hook based CLS implementations, like cls-hooked, may loose context with this change.

The relevant conversation isn't if it is too early to emit destroy but if it is too early to emit after. destroy only signals that before will never be emitted again, which is by spec true.

You are right that some context is lost. I honestly don't think it matters. Let's say you have:

function context() { // context: root
  new Promise(fnStart)
   .then(fnA) // context: root -> A
   .then(fnB) // context: root -> B
   .then(fnC) // context: root -> C
}

Then yes you are correct you longer get root -> A -> B -> C. But in terms of async stack traces, and CLS the context is sufficient.

Qard

comment created time in 24 days

issue commentnodejs/diagnostics

async_hooks performance/stability improvement plans

Proposal for reworking promise integration into async_hooks:

Regarding the promise story, I think the current strategy is fundamentally wrong. Right now the promise lifecycle is somehow intertwined with async_hooks in a way that causes all issues mentioned above.

I think the right approach is to instead rework promise integration into async_hooks such that.

  1. at the call of [[then]] in a promise or thenable, the init hook is called.
  2. at the call of the[[then]] callback, the before hook is called.
  3. at the end of the[[then]] callback, the after hook is called followed by the destroy hook.

This avoids tracking promise objects with the garbage collector, directly solving "Avoid wrapping promises with AsyncWrap if destroy is not used" and might make "Make PromiseHook support thenables" more feasible.

In terms of still providing insight into a promise lifecycle, a dedicated promise_hooks module should be created. A user can then connect the promise lifecycle with async_hooks via a promiseId that is exposed both in promise_hook and via the HandleObject in async_hooks.

This does change the default async stack, as a chain of promises would become shorted to just the last promise. I think for most purposes this is actually desired, and a user can recover the full stack by integrating promise_hooks.

Finally, I want to highlight that right now, tracking the actual async boundary that [[then]] creates via its microtask is actually very difficult, and when multiple .then() calls are used on the same promise it is actually impossible. This will be fixed by this proposal, without removing features.

PS: I know I have haven't been active in node.js for a long time. I still want to participate if you think it can be helpful on very specific issues, but the mail-storm I receive via @nodejs/collaborators makes it impossible to notice those issues. You are always welcome to email me if you want some direct input.

Qard

comment created time in a month

starteddorukkarinca/keras-buoy

started time in a month

PR closed ICLR/build

Respect aspect ratio in paper images

before and after

I checked this looks okay even on very size-constrained paper tiles, such as this one: size-constrained-paper-tile

+2 -1

1 comment

1 changed file

AndreasMadsen

pr closed time in a month

PR opened ICLR/build

Respect aspect ratio

before and after

I checked this looks okay even on very size-constrained paper tiles, such as this one: size-constrained-paper-tile

+2 -1

0 comment

1 changed file

pr created time in a month

push eventAndreasMadsen/build

Andreas Madsen

commit sha 0193c8b769d79dbc8d52a38b9b05444e55bf33ab

respect aspect ratio on paper images Unless a paper image is very wide the aspect ratio will be changed. This commit fixes that by using the object-fit CSS property set to scale-down, which causes the aspect ratio to be unchanged.

view details

Andreas Madsen

commit sha e7dab4255d0fda4e1d5ad4218231511668632072

Increase possible paper image size to 140px high With the aspect ratio fix, some images become quite small. This extends the allowed image size to be 140px in height. Manual inspection shows this does not cause any paper images to overflow their container. A more appropriate fix would be to use a flexbox container, however I wanted to to make as few code changes as possible.

view details

push time in a month

push eventAndreasMadsen/build

Andreas Madsen

commit sha 5c7834a007b9dd1308ed6f101e582fb18b020263

respect aspect ratio on paper images

view details

Andreas Madsen

commit sha f177e5d596376a962dcf033a6fa27e3305546d8b

Increase possible paper image size to 140px high With the aspect ratio fix, some images become quite small. This extends the allowed image size to be 140px in height. Manual inspection shows this does not cause any paper images to overflow their container. A more appropriate fix would be to use a flexbox container, however I wanted to to make as few code changes as possible.

view details

push time in a month

create barnchAndreasMadsen/build

branch : respect-aspect-ratio

created branch time in a month

push eventAndreasMadsen/build

Andreas Madsen

commit sha 5c7834a007b9dd1308ed6f101e582fb18b020263

respect aspect ratio on paper images

view details

push time in a month

push eventAndreasMadsen/iclr-images

Andreas Madsen

commit sha 88607f58f6b577a353d51def6d5b92cdb6021898

additional keywords for H1gNOeHKPS

view details

push time in a month

push eventAndreasMadsen/stable-nalu

Andreas Madsen

commit sha 2db888bf2dfcb1bba8d8065b94b7dab9dd178332

add iclr slides and sedl poster

view details

push time in a month

PR opened ICLR/iclr-images

Replace image of H1gNOeHKPS

The existing image is a pure-text crop of the experimental setup which doesn't reflect the content of the paper.

This PR replaces that image with Figure 1 on page 2, which is a visualization of the primary contribution. This image also works well with this spotlight awarded paper being in the network architecture category.

+0 -0

0 comment

2 changed files

pr created time in a month

push eventAndreasMadsen/iclr-images

Andreas Madsen

commit sha 580afa606e7b7d56e93b56327c62e7c6fd0e95b5

Replace image of H1gNOeHKPS The existing image is a pure-text crop of the experimental setup which doesn't reflect the content of the paper. This PR replaces that image with Figure 1 on page 2, which is a visualization of the primary contribution. This image also works well with this spotlight awarded paper being in the network architecture category.

view details

push time in a month

create barnchAndreasMadsen/iclr-images

branch : update-H1gNOeHKPS

created branch time in a month

issue commentnodejs/node

listening to sigint don't exit nicely

@Trott I see nothing ambiguous about this. I made a very clear test case. I think the dialog has been really unproductive because a few individuals are more focused on explaining how Linux handles signals by default, rather than openly discussing what would be useful for the Node.js runtime in terms of debugging.

AndreasMadsen

comment created time in a month

issue commentnodejs/node

domain migration to async_hooks

Looks like we still need to complete "Remove .domain support from MakeCallback". The depreciation code is still in master.

So I would suggest removing that code before closing this issue. I should make MakeCallback a lot simpler.

AndreasMadsen

comment created time in a month

issue closedAndreasMadsen/python-textualheatmap

How to use my own datasets?

Hello! Your project is great! I want to use my own data set. How does this work? Looking forward to your reply!

closed time in 2 months

ScottishFold007

issue commentAndreasMadsen/python-textualheatmap

How to use my own datasets?

I made a notebook that explains it in detail. https://colab.research.google.com/github/AndreasMadsen/python-textualheatmap/blob/master/notebooks/huggingface_bert_example.ipynb

ScottishFold007

comment created time in 2 months

push eventAndreasMadsen/python-textualheatmap

Andreas Madsen

commit sha 7f5a5297113012f2d73786f3d787fbc71fa42ba6

remove pip install output from notebook

view details

push time in 2 months

push eventAndreasMadsen/python-textualheatmap

Andreas Madsen

commit sha c3882d288a1c46e1f32e0c44cc9603bb383b0358

add some description to the huggingface notebook

view details

push time in 2 months

push eventAndreasMadsen/python-textualheatmap

Andreas Madsen

commit sha dbe70bff8e8dda2f5cff5cc2bdd5f5f32dbd9f53

add huggingface transformers example

view details

push time in 2 months

push eventAndreasMadsen/python-textualheatmap

Andreas Madsen

commit sha f596c7342493a260db7cab07360b8717078a4c7b

remove console.log calls

view details

Andreas Madsen

commit sha 69697716592e52d79f29279b3f21a8c8643675f4

version 1.1.1

view details

push time in 2 months

push eventAndreasMadsen/python-textualheatmap

Andreas Madsen

commit sha 9959eaaff0f625df1f059bec9e5ea2742a8f8688

fix wrong manifest

view details

Andreas Madsen

commit sha c3d5f024ec03051a2cbd9a33c8e2aebf788a7576

version 1.0.2

view details

Andreas Madsen

commit sha b233f5439a60f3b6bf0737db88f5cdedea195348

add support for format-tokens

view details

Andreas Madsen

commit sha 439c20f233825780439325144f35163f5b3c9c09

version 1.1.0

view details

push time in 2 months

issue commentAndreasMadsen/python-textualheatmap

How to use my own datasets?

@ScottishFold007 What do you mean? You construct a data structure as shown in https://github.com/AndreasMadsen/python-textualheatmap#example, how you do that depends on your application. Essentially the data structure is List[List[{"heat": List[float], "token": str, "meta": List[str]}]].

ScottishFold007

comment created time in 2 months

issue commentAndreasMadsen/ttest

Feature Request: "BigNum/BigDecimal" interface

There are ways to compute mean and variance numerically stable. See for example Welford's online algorithm. I would be happy to accept a PR in my summary module for that.

I don't think BigInt really solves anything, as it will only work for integers.

mscdex

comment created time in 2 months

pull request commenttensorflow/addons

Moving out of tf.test.TestCase in sparsemax_test.py

I'm not familiar with the new pytest system. I guess this is fine, but I don't understand why only one test was changed. Why not change them all?

gabrieldemarmiesse

comment created time in 2 months

push eventAndreasMadsen/python-textualheatmap

Andreas Madsen

commit sha 649c5a52b3d063b1ca209dc7cbf71e216c60d178

fix readme text

view details

Andreas Madsen

commit sha a733e4a918173a98e23a347b29d1abef326c3073

version 1.0.1

view details

push time in 2 months

PublicEvent

startedAndreasMadsen/python-textualheatmap

started time in 2 months

issue closedAndreasMadsen/python-lrcurve

Feature request: add a way to save the figure as a png/pdf/... file

Hello, it would be nice to have a filepath argument in the class constructor that allows the final figure to be saved as an image file (a png, or a pdf, or a jpeg, etc). Or maybe there is already a way to extract it from the notebook and to save it by manipulating IPython?

closed time in 2 months

durandg12

issue commentAndreasMadsen/python-lrcurve

Feature request: add a way to save the figure as a png/pdf/... file

I have now investigated this thoroughly. Unfortunately communicating from JavaScript to Python, the way that would be required for this, appears to be difficult. As far as I understand IPython.notebook.kernel.execute does no longer exist, but instead the iPython-widget system has to be used. This, unfortunately, has its own challenges.

I would suggest you simply use ggplot2 equivalent, like ggplot or plotnine for python, if it is the style you like.

durandg12

comment created time in 2 months

pull request commentAndreasMadsen/python-lrcurve

support 'with' blocks

Landed in cdfeac95f361241e8893fd59fd41ddbbbb9c0422

minhlab

comment created time in 2 months

push eventAndreasMadsen/python-lrcurve

Andreas Madsen

commit sha cdfeac95f361241e8893fd59fd41ddbbbb9c0422

add support for with-scope

view details

Andreas Madsen

commit sha ec8364a65dba0a22eba2b2e1b4634eaca1de334f

add publich command

view details

Andreas Madsen

commit sha a512f05dc2a32a07d6ef7b2a919eeda30a85119c

version 1.1.0

view details

push time in 2 months

pull request commentAndreasMadsen/python-lrcurve

support 'with' blocks

Thanks. Can you update the tests, docs, and examples?

minhlab

comment created time in 3 months

more