[slamdata/slamdata] New comment by beckyconning on pull request #2125: Added are you sure you want to leave this page dialog while unsaved changes
Should have or should not have?
[github]
[slamdata/slamdata] New comment by garyb on pull request #2125: Added are you sure you want to leave this page dialog while unsaved changes
The reason that was introduced is not to aid discoverability, although it's a happy consequence of that restriction. It's to ensure adding members to libraries does not break things that depend on it downstream. The same thing doesn't apply to constructors, since changing the constructors of a type is a breaking change anyway.
I get where you're coming from, I just prefer to do as little as possible when it comes to managing imports, since they're there as a necessary evil, not something that I really want to think much about when solving problems.
[slamdata/slamdata] New comment by garyb on pull request #2125: Added are you sure you want to leave this page dialog while unsaved changes
Should not have - open imports are meant to stay at the top, and a
hiding (blah) is still an open import.
[slamdata/slamdata] New comment by garyb on pull request #2125: Added are you sure you want to leave this page dialog while unsaved changes
We can drop the
(..) now =D
[slamdata/slamdata] Pull request submitted by garyb
slamdata/slamdata#2129
Will resolve #1882
[slamdata/slamdata] New comment by beckyconning on pull request #2125: Added are you sure you want to leave this page dialog while unsaved changes (assigned to beckyconning)
@garyb all good? : )
[slamdata/slamdata] New comment by garyb on pull request #2125: Added are you sure you want to leave this page dialog while unsaved changes (assigned to beckyconning)
I think we should do
enableOnBeforeUnloadConfirmation in saveWorkspace also, and then trigger disableOnBeforeUnloadConfirmation at the end of the save, removing it from queueSave. There are places where saveWorkspace is called directly, so we'd this behaviour for those as well as the debounced version.
[slamdata/slamdata] New comment by beckyconning on pull request #2125: Added are you sure you want to leave this page dialog while unsaved changes (assigned to beckyconning)
Oops missed a spot!
[slamdata/slamdata] Issue created by garyb
slamdata/slamdata#2130
We either need to add a cancel button or have it so that when re-selecting the visualisation that is currently chosen it doesn't reset the options for it.
[slamdata/slamdata] Pull request submitted by garyb
slamdata/slamdata#2131
The indicator currently be all insane on Windows (or on a Mac if you have scrollbars visible)
[slamdata:master] 2 new commits by Gary Burgess:
`slamdata/slamdata@5b60947
Fix indicator overflow - Gary Burgessslamdata/slamdata@c3cfd54` Merge pull request #2131 from garyb/indicator-overflow - Gary Burgess
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
What happens when you explicitly run a GC during profiling (the trashcan item at the top)? I tried profiling (in chrome) both spork and halogen in a minimal test for adding and removing elements. They both seem to balloon a little bit on elements and event listeners, but with an explicit GC, everything is collected appropriately (so I think chrome is just taking longer to GC nodes and handlers), which means there isn't a fundamental leak in the DOM diffing stuff.
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
The JS Heap size is concerning, because I didn't see that balloon in my test.
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
In your report, you say that it increases as you add folders? That's expected isn't it? You are adding more nodes and handlers.
[github]
[slamdata/slamdata] New comment by safareli on issue #1481: Add charts color editing / chart color palette picker (assigned to safareli, cryogenian)
While I was flying with no internet I have fetched some materials and implemented cubehelix schema. in this scheme brightness is perceived as increasing which is what we want for sequential schemes and gives great results. here is an one example https://bl.ocks.org/mbostock/11415064
Will open PR on this issue sharkdp/purescript-colors#30)
Meanwhile this is that I got:
<img width="433" alt="screen shot 2017-08-25 at 8 34 06 pm" src="https://user-images.githubusercontent.com/1932383/29727565-c2a20af8-89d4-11e7-9ef8-c31e58cef6c6.png">
<img width="443" alt="screen shot 2017-08-25 at 8 33 57 pm" src="https://user-images.githubusercontent.com/1932383/29727568-c43d674a-89d4-11e7-9238-8b5d3d12016f.png">
<img width="430" alt="screen shot 2017-08-25 at 8 33 43 pm" src="https://user-images.githubusercontent.com/1932383/29727572-c747aaa4-89d4-11e7-860a-2f81bb9bdd84.png">
<img width="444" alt="screen shot 2017-08-25 at 8 34 42 pm" src="https://user-images.githubusercontent.com/1932383/29727586-d8e12786-89d4-11e7-98ea-c8c9df7e10e9.png">
This is great result as even for 20 stops, brightness difference is still perceived!
[github]
[slamdata/slamdata] Pull request submitted by Cmdv
slamdata/slamdata#2132
Directories with large amount of folders can take time to become visible.
Added a spinner as shown bellow: :point_down:
this fixes #1830
[github]
[slamdata/slamdata] New comment by Cmdv on issue #2128: Filesystem potential memory leak
I agree with what you are saying but the fact that everything returns to being normal speed wise when you refresh the page is what drew me towards my suspicions.
Feels like event listeners should be garbage collected once the folder has been created, yes the repaint/nodes will increase as the number of files do the same. But if there wasn't some potential leak then refreshing the page shouldn't make a difference?
It's also really hard to nail things down as when you search through the code in the profile it's just endless anonymous functions.
You can have a look at the zip file I attached, inside is a .json which can be loaded into the performance tab (right click anywhere inside panel)
<img width="555" alt="screen shot 2017-08-25 at 21 05 37" src="https://user-images.githubusercontent.com/3036557/29730715-4499c39e-89d9-11e7-94e6-7346879a12ee.png">
[github]
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
Feels like event listeners should be garbage collected once the folder has been created
Not sure what you mean. Every row has event listeners on it, so as you add rows, new event listeners are created. Why would adding new rows remove event listeners?
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
FWIW, I'm not saying there isn't a leak somewhere, but I don't think we do anything on top of Halogen that should result in leaks, and I haven't been able to reproduce leaky behavior with a simple example yet.
[github]
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
I think that Chrome is just taking a long time to garbage collect the nodes and handlers. When I initiate a manual garbage collection, things clear up, as indicated by this profile:
<img width="812" alt="screen shot 2017-08-25 at 1 24 31 pm" src="https://user-images.githubusercontent.com/144058/29731324-dce1a5d6-8998-11e7-94ac-762d6a5c47bd.png">
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
Not sure why it's taking forever to clear it up, though.
[slamdata/slamdata] New comment by beckyconning on issue #2128: Filesystem potential memory leak
maybe a chrome bug lol!
[github]
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
<img width="802" alt="screen shot 2017-08-25 at 1 36 50 pm" src="https://user-images.githubusercontent.com/144058/29731738-7bbbeff8-899a-11e7-9a89-05f1df8b5a17.png">
In this timeline, I started the recording by hitting garbage collect, adding a bunch of folders, navigating to the root, and then hitting garbage collect again, where the memory returns to what it was originally.
[github]
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
<img width="153" alt="screen shot 2017-08-25 at 1 42 43 pm" src="https://user-images.githubusercontent.com/144058/29731934-4ed94692-899b-11e7-8ba6-d7d29a043d84.png">
Additionally, here I took a heap snapshot at the root, then after adding a bunch of folders, and then after navigating back to the root again.
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
Of note, is I did not initiate a manual garbage collection when taking those three snapshots. But maybe Chrome does that anyway when taking a snapshot.
[github]
[slamdata/slamdata] Issue created by damonLL
slamdata/slamdata#2133
The icons near the _"Page X of Y"_ control are flipped. The behavior based on their location is correct, but the icon is incorrect.
The first page icon (|<) and previous page icon (<<) should be flipped.
Similarly the next page icon (>>) and last page icon (>|) should be flipped.
This has been my experience with applications containing pagination controls. The first page and last page icons are typically on the outside of the icon set. I don't think this is a regression, it has been this way for as long as I can remember.
[github]
[slamdata/slamdata] Issue created by damonLL
slamdata/slamdata#2134
When I have a series of data in a line chart, I don't see the legend near the bottom for the colors like I do in the bar chart. See screenshot below.
<img width="615" alt="linechart-legend" src="https://user-images.githubusercontent.com/7375598/29733834-57ecf6a0-89ac-11e7-95d4-23cb03242fe7.png">
[slamdata/slamdata] New comment by garyb on issue #2133: Pagination icons in Preview Table and Pivot Table are flipped
I got confused for a sec reading this, but you mean flipped in the sense that
>| and >> should be swapped (etc.), not that they need flipping to face the opposite direction, right?
[slamdata/slamdata] New comment by damonLL on issue #2133: Pagination icons in Preview Table and Pivot Table are flipped
@garyb - yeah, I feared I stated it confusingly. What you describe is exactly it.
[slamdata/slamdata] New comment by damonLL on issue #2133: Pagination icons in Preview Table and Pivot Table are swapped
I've updated the description and the title to reflect that change. THanks @garyb
[slamdata/slamdata] New comment by garyb on issue #2133: Pagination icons in Preview Table and Pivot Table are swapped
Thanks! It made sense when I looked at them in the frontend as it is, just wanted to double check that was definitely the intent.
[github]
[slamdata/slamdata] New comment by safareli on issue #1481: Add charts color editing / chart color palette picker (assigned to safareli, cryogenian)
I have switched to cubehelix based palettes. here you can see difference:
<img width="1224" alt="screen shot 2017-08-26 at 1 13 48 am" src="https://user-images.githubusercontent.com/1932383/29739575-e5c3be1e-8a51-11e7-9e2c-8d6909944999.png">
One of the main feature is that if you use grayscale for example all cubehelix based palettes have linear change of lightness, which makes it much useful when we want many colors of of palette.
(first 3 chapters of paper describes it much better http://astron-soc.in/bulletin/11June/289392011.pdf)
[slamdata/slamdata] New comment by safareli on issue #1481: Add charts color editing / chart color palette picker (assigned to safareli, cryogenian)
See updated example: https://bl.ocks.org/safareli/57af3a9f4ab6c44bf121c0d5603a1441
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
This is an unrelated thing, but while we're making changes to the listing, perhaps we should add a case that shows a message when a directory is empty too?
[github]
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
Could useH.modify (_ { items = Just $ nub $ cons item previous })
here I think
[github]
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
This is a revert of my fix #2131
[github]
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
I think it might have done this slightly differently actually. Instead of defining this DSL-based function I'd probably have just defined it purely (State -> Array Item). That way it can be used with gets for the few cases that need it that way, and for the rest it can be applied to the s in the modify cases. It's more declarative that way, rather than happening as separate imperative steps.
I'm not saying it needs changing, just giving my 2p on code style/design for this kind of thing.
[github]
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
Perhaps move this below eval?
[slamdata/slamdata] New comment by jdegoes on issue #1481: Add charts color editing / chart color palette picker (assigned to safareli, cryogenian)
Really amazing results. <3
[slamdata/slamdata] New comment by jdegoes on issue #2071: Mimir as the default mount pointing to pre-baked examples we package. (assigned to Cmdv)
thumbsup emoji on
local being the name of the Mimir mount in the file system, for now at least.
