Path of Item editor

Step 1:  I have implemented ItemTooltips from scratch.
We should have taken the procurement tooltips, it was too much work, but it is late now :)
screenshot:
https://cloud.githubusercontent.com/assets/2779184/7333536/de4d30e6-eb72-11e4-88ac-c072f2da349c.png
dev screenshot - nonequipment items were added for debugging purposes
https://cloud.githubusercontent.com/assets/2779184/7333532/b730880a-eb72-11e4-97ac-1712e0ec7796.png
There are some things we should think about:

I have added graphics used in tooltips as resources. But we cannot distribute graphics for all items and gems, it is should be loaded on demand an we need complete list of slots, stats and images for base items it can be downloaded and parsed from http://www.pathofexile.com/item-data/weapon and http://www.pathofexile.com/item-data/armour

Loadout editor should look similar to POE inventory screen. But this cannot be done in sidepanel, so Popup window or second tab behind the tree?

Save crafted items locally and share them across builds?

I'll start working on item editor. Without the base item and implicit mods for now, just some item crafting window with mod selectors and resulting tooltip.

Looks good, would want the other guys to check it out as well though.
@SpaceOgre @l0g0sys

Checked code, no complaints except I'd change name of Images\ItemImages folder to something like Images\UI, as it doesn't hold item images at all :)
Regarding things to think about:

Images of items cannot be downloaded on demand. "Offline" term in Offline Skilltree Planner is very important :)
So, i think we should distribute only images of gems and base items. I couldn't care less that item doesn't look exactly like in game.
The base items with stats will be kept updated from Path of Exile Wiki as we have this already working for gems.

This should be tought out together with other UI components we still need or we will need in future.
We still need component for choosing bandit rewards and buff/aura controls to turn on/off equipped buffs/auras ("values" of these components should be part of build).
Component to choose difficulty (normal/cruel/merciless), but this could be just placed in menu as it's not part of a build and it's only to apply few mods according to choosen difficulty.

And for the future i'd like to be able to play with character and opponent (monster) status like elemental status (frozen, shocked, ignited, ...), low life/low mana, etc. to be able to apply appropriate conditional mods.

This relates to issue (2). As there will be some either drag & drop interaction with equippment UI component or simple click and choose slot to equip to.
So I was thinking about something like virtual stash stored locally, so you could manage tabs and their content and put there crafted items.

Sadly I have a lot to do at work atm, overtime have been ordered :(
So I'm not sure when I will get to the to check it out properly, but I think you got this one :)
But what I can say is that, from the screenshoots it looks really good.

@l0g0sys

There is like 500 different item bases :) 15KB each. And bazilion of uniques :/. Item editor can work without them, but there should be at least option for user to download the images.

My vote is for tabbed interface. 1 Tab skill tree planner, 1tab Loadout editor, 1 tab combat simulator. SomeButton and big popup window will be clunky when switching between Pasives a equip when finetuning build

3)Yeah.. problem is with "something" you need support for item search and probably lot of other stuff :) and i don't have any clear idea how it should look like.
@SpaceOgre
We have at least 6 weeks before beta ends :). I will do the UI and basic functionality, but then i would appreciate help with the data mining.

That's small price for offline functionality which is essential to this app. Game client has 6GB+ and noone complains :)
Trust me, even if you made every item look same, ppl would still use it and be happy that it delivers what it should.

Don't know what you mean by combat simulator. But it should be possible to show Character sheet together with either tree/equipment/anything like it's now. I want to see effect of skilling node immediately :) But yeah, something like middle part of main window view could be tabbed.

There is no problem at all :)) You don't need search at start, if you make it possible to name each tab as you want. You can keep your stuff organized pretty well this way.
Search is "nice to have" feature not necessity. We should start with what's "must to have" and make it work, and get it tested, instead of waiting months and months until very rich functionality will be done and in the end it won't really finished anyway :) There is always something you can make better.

Regarding, data mining. It's on my TODO list. I'll prepare model and stuff.. just still checking around about possibility to have it ready for taiwan/russian garena support.

I was thinking DPS calculator plus line graph with DPS increase/decrease, with different stats on X or something :). Later someone can Add auras, potions etc... I am just reserving space.

No problem with functionality, problem with design. Lack of planning in WPF usually leads to throwing it away and  starting over. My first serious work with WPF was adding features to to extremely screwed up application. I took a half a year of replacing small parts and then trowing it away when replacing larger parts to make it somewhat manageable, without any significant changes to the user. And now i am just really biased from rushing UI.

I have explicit item mods datamined. Rest is free to take :)

Step 2: Inventory screen
I have added tabcontrol to main window, tab switches are placed on right side of skillpoint counter
screenshots:
https://cloud.githubusercontent.com/assets/2779184/7383622/f11ecccc-ee22-11e4-9ac6-32fe5b1c4d46.png
https://cloud.githubusercontent.com/assets/2779184/7383625/f6fa842e-ee22-11e4-8fbd-7c454c79f73d.png
Next step is some default graphics for items (I am thinking some vector graphics silhouettes instead of empty blue rectangle), local item storage on inventory screen and Drag&Drop interaction between them.
I am reluctant to use actual POE item models, because it can confuse user. (why this majestic plate have graphics of crypt armor)

This looks really out of place to me :)
Putting in-game UI elements into modern looking app, doesn't fit too well.
Maybe create simplier equipment UI, like only outlined gear slots with
.NET drawing capabilities and themed colors...
Same with tooltips. Was thinking that maybe our own visual
interpretation would fit better and it would also allow us to display
more informations which are not displayed in game.

Designing it similar enough with the ingame graphics to not confuse users, but better fitting to overall app design is way out of my league.
I will focus to make it functional for now. But feel free to re-skin it as you like or if you know someone willing to draw it i can make it work :)

default white graphics for item classes.
https://cloud.githubusercontent.com/assets/2779184/7448255/3c20dada-f215-11e4-8297-6141f7a9c200.png

I have implemented downloaders and item parsers for item bases on pathofexile.com
https://cloud.githubusercontent.com/assets/2779184/7448259/5feed480-f215-11e4-8fb8-f3f5ee21b200.png
(Where is item base list Quivers?)

I have added "Redownload Item Assets" to main menu to generate item base list and download images for all bases.

We can distribute list without item images, UI will fallback to white outlines (or something that will replace them) and user can optionally download full list

"stash" part is placeholder for something better with search, sorting, etc

there are no dowloaders for quivers, uniques, gems, flask and all nonequipable items

Actually most of new UI parts are probably placeholders :)

Todo list (in order):

item creator
gear switching (drag and drop, search ...)
"Gem Slot" ItemVisualizer in tree
refactoring, bughunt

Good work, those placeholders are interesting though :p something we can worry about later.
A note on the item creation: we are going to need it to create jewels as well as inventory stuff, so it may need to not just be attached to the equipment window.

I was thinking dialog window for creating items, so no problem :)
There is little problem with item class identification on items. If they are not equipped when loading, there are no ouptlines etc. but it will be solved soon,

Alright, very cool! Thank you for doing this :)

Quick update.
https://cloud.githubusercontent.com/assets/2779184/7462459/e1b14a10-f2b1-11e4-8675-d0822d9234db.png
Item base type parsing code is completed.

I really love those white outlines (and the stash grid also looks really neat). I'm pretty sure we can get away with a "simplistic" inventory background to bring it in line with the rest of the app.
Overall this is looking extremely promising!

I have added really basic item crafting.
Don't freak out from added lines 10132 are XML data.

How do you/will you handle double rolls (x-y damage)? Just curious...

In the UI, I'm not. Yet. I will try two sliders and slider with two thumbs. Bind it together so when you change tier on one it will automatically switch on the other one. And select the better looking solution :)
Hybrids rolls are stored same way, so it will kill two birds with one stone.
There are other prolems:
Add sliders for implicit mods.
Make sliders ranges between mods.
Make follow with integer values.
What to do with non integer mods like life regen. (They actually are X per minute integer value showed as X per second float)
And the biggest issue of all: Add custom serialization of Item class, so you can save created item.
(I wonder about Raven.Json wrapper, I didn't see any part of code that can't be done with plain Newtonsoft.Json and most of the time with better LINQ syntax)

There should be text input next to slider.  They have ranges too as
explicit mods.
Real in-game Life regen float is actually rounded to integer in JSON
item data. But not sure we should follow this rule, as at some point GGG
might decide to export real values. So slider should just change value
with step of 0.1 instead of 1. Just fake it now, later there will be
flag on mod if values are integral or decimal.
Regarding Raven vs Newtonsoft, i don't know. Both were there when i
joined project. We should pick one and discard other one that's for sure.
Just we should hold in mind there might lot of item data being processed
in future. So i'd prefer fastest one.
In general, we need to visit each node of JSON tree anyway so i can't
see any benefit using LINQ here at all.

There is Textblock .. I Can just change it in textbox + some number handling and it should work. Its not very important for now.
Actualy not entirely .) Each explicit mod in craft window is parsed List of tiers (Each tier can have multiple mods etc.) ported from some of my other code.
All mod values are always Integral. Mod is specified as "Base Life Regeneration Rate Per Minute" values are integral x/minute (transformed to floating point x/sec when showed). I have to handle it separately to show values x/sec, so some additional processing is not a problem.
Raven is wrapper around Newtonsoft. I assume, that there was point in time when Newtonsoft didn't support LINQ style work with JSON (analogous to XElement for XML) (or something else), but they caught up at some point and now they have better interface than Raven. Performance is not an issue I can parse-> modify (triple the number of properties)->serialize->push to DB ~5000 items per second :) on 1 thread ~3.5Ghz

Yep, tiers are the only difference between explicit and implicit mods.
But there is no difference value/format-wise.
So you can represent implicit mod as single tier explicit mod internally.
Not sure where did you get that info about regeneration being per
minute. Check our Compute.cs, fom line 2022. There is calculation of
life regen.
No value conversions at all. There are only 2 mods: "#% of Life
Regenerated per Second" and flat one "# Life Regenerated per second".

I have generated affixes from modlist, parsed trade forums to pair them with items, stored it in relatively complex data structure.
The state of implicit mods is String name + string value for now :) Not a problem just more work.
There was discussion about the difference between tooltips and modlist when I started playing POE (end of original closed beta)
In skill tree they are #per second. (but who knows how they are handled in background)
Item mod is per minute (http://www.pathofexile.com/item-data/suffixmod http://www.pathofexile.com/item-data/jewelry)
The thing is: As result you can get Life regen from 1 to 7 in 1/60 life per second steps and this is rounded to 1 decimal place when displayed.

Not only in skill tree, open JSON file.. there is life regen in seconds.
EVERYWHERE TODAY is life regen in seconds :)
Those mods on official page are either calculated from new internal
representation to old one just to make that page compatible with old per
minute system.
Or they are not even updated anymore.
That's what you get for using such old-school inflexible sources :)

Old-school inflexible OFFICIAL sources. :)
JSON File = Tooltip. Its not serialized Item, it is serialized View of Item. And its not exact ingame tooltip.
This is an academic question, I have two choices with same result

add a set step size for all mods. (1 for nearly anything and 0.1 for fixed regen)
for fixed regen divide value by 60 when displaying and saving to json :)

I choose 2, just because I think it follows ingame design.

I know, that's why you need to parse mods and create (in case of hybrid
mods more like guess) internal representation from JSON data for the
time of crafting. JSON data is what's going to be deserialized or
serialized in the end. And it doesn't matter which "real" mods you have
because "JSON" attributes are what matter in app outside of crafting.
I'd go with 1, as that's what is really communicated between game
client, web forums, item-data API and players and, i think, our app
should too.
I'd not go for some "maybe game server/DB internal" stuff.

I like maybe stuff:
Lets look at random distribution of values.
If you have to choose randomly one of (1; 1.1; 1.2; ... 1.9;2) the probabilities of each value will be same.
If you have to choose randomly one of "Showed values"
(roundToOneDecimalPlace(1, 1 +1/60);...roundToOneDecimalPlace(1 +60/60))
Probability of 1 is lesser than probability of 2 and other values have same but bigger probability than 2.
It have no impact on current interface, but if I want to compute percentile of how good rolls in particular tiers or say "there is 1 in 8964987 chance to roll all rolls same or better with BlessedOrb" I will need that.
The distribution of 1/60 is fairly flat, but the rounding is doing evil things to it :)

Ofc it would have impact on probabilities of values of such mods. But
the question is, are they really rolled like that? :) Maybe somewhere is
dev thread about it.
Even then, i couldn't care less about probabilities if it should make
complications to 99% of app functionality. You still can make tweak in
that last 1% to get awesome exact numbers if you want.

Yeah, but amount of work needed is same in both scenarios (1 IF + 10 lines of code). Craft window have no influence on the rest of the program. No complications, just future proof option to add some more functionality.
Actually I would choose it even if it required some extra work. My experience indicate, that it would save more work in the future :)

Multimods are now working, sliders are snapping to numbers

And code added for regeneration:
if (aff.AliasStrings[i].Contains(" per second"))
{
      tics = tics.Select(t => t / 60.0).ToList();
}

Very nice! Looks great :)
On May 8, 2015 10:51 AM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

Multimods are now working, sliders are snapping to numbers
[image: multimods1]
https://cloud.githubusercontent.com/assets/2779184/7542182/f6ef3908-f5ba-11e4-83f1-f6199295d972.png
[image: multimods2]
https://cloud.githubusercontent.com/assets/2779184/7542183/f939f450-f5ba-11e4-8778-4bb10d44c802.png
And code added for regeneration:
if (aff.AliasStrings[i].Contains(" per second"))
{
tics = tics.Select(t => t / 60.0).ToList();
}
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-100310896.

I have removed raven json wrapper and switched Json.NET to nuget package
There is significant progress in Item crafting:

implicit/explicit/crafted mods can be now manipulated in crafting window
Base Item is updated with changes -> tooltip is reflectinng actual status of item
raw properties are visible in tooltip (they are not updated by mods for now)

So the next steps are:
Merging mods with same name to 1 line in tooltip
Applying "local" mods to local properties. ( this should enable to add Quality slider)
And finally saving and loading crafted items

properties are now affected by local mods..

tooltip mods with same attribute are now merged together
all properties should be now added and modified by local mods correctly

This looks amazing man! Seriously, thank you :)
On May 10, 2015 1:00 PM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

tooltip mods with same attribute are now merged together
all properties should be now added and modified by local mods correctly
[image: craft final]
https://cloud.githubusercontent.com/assets/2779184/7556004/c0adbf76-f75f-11e4-83d8-7a33f02a2570.png
[image: propcraft]
https://cloud.githubusercontent.com/assets/2779184/7556008/de7592d6-f75f-11e4-9d6c-d9805c3c6afc.png
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-100689376.

No problem. I am really bad at this game, i need fully working planner :)

I didn't have lot of time last week, but I have made some minor progress - I can save and load crafted items now. And i am working on stash to make it support drag&drop a item virtualization (draw only showed items) and fulltext search...
But this made me thinking, and I have some thoughts that need little discussion :)

Do we have to save crafted (manually in PoeSkillTree) items in original JSON format?

I think, that it would be better to save crafted items as affixes + selected values. This would enable edits (If you roll item with divine orb you can edit crafted item and simply change values, instead of creating new item)
This would be problem only if we have to support exporting crafted items for some other tool (I don't see any reason for this)

Translations (This can wait now, but it have to be solved eventually)

There are some (lot of) places with Item attribute strings in conditions. ("per second"/"per minute", "Evasion Rating" / "Evasion", "To all attributes" split into "to dex"+"to str" + "to int" and some more in original skill tree and equipment parsing
To support direct loading of Russian or Taiwanese Skill Tree and items all these conditions have to be modified for each supported language. Also any future multimod will have same problem.
I think the reasonable solution is to use English internally and only translate the showed values.

We can always get current Garena tree in English, Russian and Chinese and make translation table automatically
Item attributes will have to be translated to English on import and back to given language when showed but this seems simpler than to add specific code for each added language. Changes to mod names are not as frequent as changes to tree so it should be ok  (I think that only master signature mods were added since original closed beta, some minor ones on unique items, and now jewel mods)

Some Property like "TranslatedText" with automatic translation lookup added to Attribute and used in GUI should solve the translation problems.(In code we can continue to use "Text" property)

It's simple :)

If you want to edit items, then you have to allow editing of existing items which comes in JSON format with it's limitations. All you need is make factory method like MyCraftingItem.CreateFrom(ItemAttribute.Item), and once you are done fooling around with sliders you replace item in slot (stash or equipment) with craftingItemInstance.ToItem(). So there is no reason to use properietary storage for items at all. You want to intoduce mini-games to app? Sure, why not. You can do craftingItemInstance.ApplyDivineOrb(), craftingItemInstance.ApplyJewellerOrb(), etc.

In the end, there will be 2 groups of people... "realists" which will craft items they found on poe.trade, and want to see how they will perform if they buy it, or rise the value of crafted mod on ring, because they leveled Elreon to level 7, and other group "dreamers" which will be crafting perfect 6x T1 items just for kick-ass :)
You think we won't need exporting crafted items? The moment, it will be easy to edit/create full fledged builds with this app. There will be some guy who will think "why not to make some build gallery" so you can import build there and then link it to build forums.

Yep, it's not an issue right now. But it should work like this:

As you said, internally all calculations won't be needed to be touched at all. Translation will occur on input/output.
Mods (attributes) will be translated as whole. So "+# increased Attack Speed" with it's float[] values will be translated like "+{0} increased Attack Speed" formatted with values after translation. No need for TranslatedText property or anything because application doesn't work internally with ViewModels.Attribute at all, thouse are used purely for UI. So you populate those with already translated texts.

editing "arbitrary" items

items are ambiguous, same mods can be generated by several different combination of affixes and tiers, you cannot modify them until you know the exact attributes and tiers. So you cannot apply divine orb on item parsed from JSON.

Analysis on item and generating all possible combinations of tiers that results in given item is doable. (I have prototype). But i am not sure it should be released to public. It enables trade scamming with less effort for some individuals (probably like 15%+ of trade chat :)). And i don't like the concept of taking currency from new players in game like POE, where it takes half a year to accumulate decent knowledge of game, and trading is the most demanding part..

I think WE as developers of POESkill tree will not need exporting. This is opensource project IF someone wants to make that webpage he can write the export part of application himself and put up pull request, or ask nicely and fill an issue. I'm not against writing more code to avoid doing it in future, but this isn't feature that will be directly usefull for POESkillTree ever.

The conditions are in item mod not attribute ItemMod. but you are right, translation can probably be in "InsertNumbersInAttributes" method and it should work

editing

We know how item mods works and all troubles related with it. But i want to import JSON build of my character and be able to edit it. And if not me, then someone else will make it happen. I can assure you that once there will be working crafting UI, we will make editing of imported items possible.
You cannot scam with any third pary tool. It's not possible. In-game chat and forums item links work with existing items only. You cannot link anything without owning it. Unless you want to sell "shiny uber armor for 200ex" which i doubt anyone will be interested in if it's not linked and verifiable.
My whole point was, that if we solve editing of JSON-based items, then we don't have to discuss exports at all.

Implementation details are not imporatnt atm., and i don't hold whole model in my head. The point was again, it's pretty simple :)

No but you cant Ctrl+C on linked item -> in popup window you will see 3T1 mods with chance to get given value, probably with message like "T1/T1 Phys combo, 96% rolls" buy it for 1C and post for 10Exa on forums. (I can do it right now, I was simply too lazy to remember the Tier values and made the tool). There are some people on trade channel trading currency on ridiculous exchange rates scamming newbies. Tool like that will enable them to it with items without much effort.

My point was "it should be done this way" Is there any reason not to?

Still i cannot understand what it has anything to do with our application :)
So i Ctrl+C someone's item on /trade and paste it to notepad. Now what?
You mean that someone can change that wall of text and paste it back to /trade and try to sell an item based on that text, or what?

You paste it into our crafting (import item from clipboard - already planned feature). It will tell you exact mods and tiers, and identify extremely valuable items without effort and any knowledge of available rolls.
You can now buy the item extremely underpriced, and resell it for a lot more, without effort.
Same thing as spamming trade with "buying exalts for 10C" there is always someone that will sell it.

There is already tool doing this and you don't even have to leave game client as i think it's built upon AHK script. Not sure anyone blamed author for doing it :))
This is definitely not a deal breaker for ability to customize imported items from JSON. That's what peaople were asking for.

I am aware only of one autoit script and it does not work correctly with
multiple mods on same stat.
On 20.5.2015 16:25, l0g0sys wrote:

There is already tool doing this and you don't even have to leave game
client as i think it's built upon AHK script. Not sure anyone blamed
author for doing it :))
This is definitely not a deal breaker for ability to customize imported
items from JSON. That's what peaople were asking for.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-103904739.

The only thing that can really happen with being able to tell tiers is that
game knowledge will be a little wider. Honestly it doesn't matter if we can
have tier or not. Just having this crafting system people will go crazy for
it.
On May 20, 2015 7:36 AM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

I am aware only of one autoit script and it does not work correctly with
multiple mods on same stat.
On 20.5.2015 16:25, l0g0sys wrote:

There is already tool doing this and you don't even have to leave game
client as i think it's built upon AHK script. Not sure anyone blamed
author for doing it :))
This is definitely not a deal breaker for ability to customize imported
items from JSON. That's what peaople were asking for.
—
Reply to this email directly or view it on GitHub
<https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-103904739
.

—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-103908498.

Original question was:
Is there any problem if I save crafted items in different format than imported items. I want to do this to enable editing of crafted items.

No i don't see any problem. We will just implement editation of existing items later.

It doesn't matter how you save it. Although people may want to share their
items, so when exporting they need to be in json, I think.
On May 20, 2015 9:40 AM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

Original question was:
Is there any problem if I save crafted items in different format than
imported items. I want to do this to enable editing of crafted items.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-103953392.

It will be JSON, Loadable by PoeSkillTree. Just with mods+tiers+values instead of attributes.

How will you handle items that a user wants to load from their character?
Or maybe I missed that post.
On May 20, 2015 9:52 AM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

It will be JSON, Loadable by PoeSkillTree. Just with mods+tiers+values
instead of attributes.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-103957170.

Import stays as it is now, Items just will be also added to global stash. Only difference for user will be that imported items cannot be edited.

I think that might be a big thing to try and do, or I can see it as a
highly requested feature. It should just be a simple converter, right?
On May 20, 2015 10:05 AM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

Import stays as it is now, Items just will be also added to global stash.
Only difference for user will be that imported items cannot be edited.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-103962627.

Full builds, with items and everything else, should be able to be traded between players. Hopefully this means breaking new ground. Currently the websites that allow build sharing are pretty subpar. It would be nice to have items be fully exportable so that there is an ease of sharing items. There shouldn't be a reason a player can't import his/her own items in order to edit them and see what that little bit will do.
Honestly though, if you don't want to implement it, we can implement it later :P Seriously though, thank you for the work you have been doing!

I thought the problem was converting the "combined mods" (e.g. pure %phys gets added to the hybrid acc. + %phys) back into the affix form? With the help of master crafts you can sometimes tell what is going on, but for certain affix combinations it's impossible (pure %phys, hybrid phys+acc, pure acc can be indistinguishable from pure %phys and pure acc, same for ev/es/ar + stun recovery on armor)...

Not so simple, i am not entirely sure we should do that (see the long posts in discussion). But doable and not too much work if i adapt my existing code.
Just add it to the todo list, and we'll see :)

Honestly, just throw it as the last thing. If people can't edit their own items oh well. @MLanghof makes a good point that I didn't think of. It might be easy to go from your crafting system to JSON but not the other way.

Crafting

Crafted items are now saved into stash (ok button in craft window)
Crafted items now support serialization and deserialization in default json item format
Editing items is postponed until everything else works :)

Stash

stash is changed from placeholder to something slightly better
items are now shown on demand (virtualized)
stash can be reorganized by drag&drop
stash is one long scrollable column

inventory

i have made somewhat simpler and better design for inventory
you can drag&drop items from stash to inventory
"Item attributes" and "ItemList" changes dynamically with inventory changes
items can be removed from inventory by mouseover and 'delete' key

Todo:

removing items from stash
stash tabs (on left) are placeholder for stash "bookmarks", click will scroll stash to bookmarked position
search feature for items
i have made scrollbar that supports visual studio like markings. Stashtab bookmarks, newly added items and search results should be marked on it.
more changes to ItemAttributes are inevitable. It is mess now and I have plans to change how equiped items are saved and add support for items without inventory slots (for jewels)

https://cloud.githubusercontent.com/assets/2779184/7951478/fa2638dc-09a7-11e5-982f-bc7b82887336.png

Looking good! Question about the bookmarks, are they nameable?
I honestly like the idea of one scrolling interface, really make it simple.

I plan to add name and color for bookmarks - like premium stash tabs. (Now they are just placeholder for styling)
For each bookmark there will be line (with same color) on scrollbar.

Alright, very cool stuff! Thank you for doing this :)
On Jun 2, 2015 7:34 PM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

I plan to add name and color for bookmarks - like premium stash tabs. (Now
they are just placeholder for styling)
For each bookmark there will be line (with same color) on scrollbar.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-108166040.

Looks good. One, question. Can those scrollable stashes be restricted in size?
We will need to be able to display regular stashes as well as main inventory of JSON build file.
Was thinking about removing items. We should not forget about people more and more using touch screens. So i'd suggest to created something like "Trash Can" slot below equipped items where you can just drag & drop item to remove it.

I always assumed there will be one big global stash + local inventory for each build. So no,  stash cannot be restricted in size and it is automatically growing with content.

Main inventory of character is restricted in size (12x5) and we should conform to it.
Idea of global stash isn't bad, just we have to figure out how to keep it organized once we will want to import stashes using get-stash-items.php API.

There is no reason to have character inventory, there are no items like diablo 2 charms, that change build stats when placed in character inventory. One global stash with bookmarks and search should be good enough for item storage.
And if we introduce some place for item swaps saved with build i don't see reason to restrict its size.

There is simple reason :) It's there. It's part of JSON build, so why
not use it? You can simply put there alternative items for build to use
and share it altogether in standard JSON format which allows it. And you
can use it as swap place at same time. Guess, you don't remember how
poebuilder.com looked like before they removed crafting. If they ever
introduce it back, we would be able to use our builds with that site
right from bat.
You restrict size if you want to stay compliant with standards. Game
defines size and organization of inventory. Anyone implementing anything
related to character inventory will conform to same standard. If you
want to communicate between 2 systems, you have to have both systems
compliant to same standard.
This is how you develop application able to communicate with external
systems immediately or in future.

If you want to communicate between 2 systems, you have to have both systems compliant to same standard.

In our case, it is not to be expected that GGG will import stuff from the tool to their servers. We need to comply with their API (obviously), but there's no need to maintain compatibility with the data structures we receive.
If we want to dump all the items from the player's stash into one big scrollable space, we are free to do that. It's easier to find items in there via search (especially with that highlight-scrollbar) than when things are split over 100 tabs.
I see absolutely 0 reason to limit sizes. "The game does it" -> The game has good reasons for doing so (gameplay reasons for inventory, stash tabs because the tab sales is how GGG makes money). We don't.

No, i didn't mean by external system game itself at all. Lol :))
I meant other tools which will implement stuff by game standards.
poebuilder.com was one example, it had swap space of same size as main
inventory.
It just would be nice to be able to communicate with such tools using
game standards.
It's may be far fetched future, but i like to take future development
into consideration when i'm designing something.

@l0g0sys

there is no specified format for character build, so there is nothing to be compatible with, actually we can specify one.
there is no limit on size in inventory JSON. Game just doesn't allow more items.
Game standard is items in json array. Item format is relatively easy to display nearly plaintext. But the format is actually very unfriendly for tools.
one stash interface will be more user friendly
I wont do it :) Certainly not in

@MLanghof
I have limited horizontal size to 12, because it would require 2D indexing for items. (and it would clutter the interface)
Vertical limit is insignificant, vertical item position and height is saved in range tree. When stash scrollbar changes rendered items  are found by querying tree  for all items intersecting with displayed vertical space.

Think you are looking wrong way on JSON data you get from get-items.php API :)
It's part of the build, and we are currently using it as part of the character build.
The chance that this format will be used by any other tool is almost 100%, because everyone wants to integrate with game data provided.
The chance that any other tool will impose limit for displaying content of main inventory to 12x5 is almost 100%, because everyone wants to integrate with game data provided.
I don't care if you make one stash or million of them, i want you to take these facts into consideration, that's all :)
We will be using JSON data format for data exchange now and in future, i can assure you that we will.

To put it simple and stop chain of unnecessary comments:
I won't implement character (build) specific inventory in any form
If someone would like to add this later, the only problem will be that old builds will have empty inventory. So no problem at all.

Noone said you have to implement it :))
All i wanted was to make sure, you are not going wrong way and we won't
have to scrap lot of code you invested time into, just because it won't
be possible to adapt it for incoming features.
That's all.

Honestly, I don't see any reason to share the inventory when you can just
equip the items you want. We can always add something in later or just
throw items in MainInventory into the stash

I found quite lot of builds on forums with suggested alternative items.
Would be nice if one can create build with equipped items AND with
alternatives in main inventory.

For example, I want to play around with my current build and try other 5
items i have! So I'll put those 5 items to inventory of my character and
export its JSON. After import, i can just equip anything i've put in
main inventory in-game. And i don't have to craft anything!
Or you can borrow items from guildie for a bit just to export them in
your character inventory and you can play with them in app. No need to
craft!
In the end, it doesn't matter what for it will be used, I can come up
with many uses. I see it as wasted functionality as it's already there
in JSON and we will just ignore it.

I can see your point, but if he doesn't want to do it then we can just do
it later. :)

Of course!!! Never said anyone to do it or when to do it.
All i asked was:

Looks good. One, question. Can those scrollable stashes be restricted in size?
We will need to be able to display regular stashes as well as main inventory of JSON build file.

In future, I'll want to import stashes, and interact with main inventory of build i import. That's all.

Import is no problem - Importing was first feature I have added to stash, just to have some test data for item visualisation and tooltips..
I reread the stash conversation and I have not mentioned that same comparison as in "Passive Attributes" (#94) should (and will) be used on "Item Attributes" and "TotalAttributes".
Build comparison is the reason I think character inventory is not viable feature

With character inventory, comparing equipment will revert to remembering numbers and switching equipment. In the long run someone will want to add equipment set comparison. (for example by supporting multiple equipment sets, and some comparison by selecting equipment set).
And every new feature working with character attributes (like DPS calculator) will need to support equipment set selection.
IMO, from user perspective it just doesn't make any sense to compare equipment and tree differently too.
Different item set should be just different build. Right now it's not very user friendly but with #14 and #73 solved, character inventory would be just another unnecessary and confusing feature.

I can imagine virtual (or linked) builds in "build set" ( from #14) that will share same skill tree and have different items. But from perspective of any other part of application you have just "Loaded Build" and "selected build"

and hypothetical DPS calculator will work implicitly, because every item set is just another build :)

In future, complete build comparison (tree + equipped items), main inventory from JSON won't play any role. Same way it doesn't play any role now. Items with MainInventory slot are silently ignored when building list of equipped items.
The idea of using character's main inventory from JSON came from the fact, that it's easier to parse it from JSON, which we are already importing and parsing. Opposed to implementing stash import or whatnot import functionality, which could be delayed and people wouldn't moan too much, because they would be able to use main inventory as simple "import few more items than what you have equipped only" feature and all that with just single imported file we are already processing.
So, i think we should stop arguing about it already, as i'm unable to describe the whole concept of using character's main inventory more accurately, then i already did in our long conversation. :)

Update :)
Stash

Items can be removed from stash (delete key - for now)
added highlighting for search
added marks for bookmarks

Bookmarks

Stash bookmarks can be now added and edited
save and load not implemented yet
Position of bookmark cannot be changed yet
Stash bookmarks are now visualized on scrollbar (horizontal colored lines)
click on bookmark will scroll it into view

Search

Basic search is implemented. (searching only in item Base type)
Found Items in stash are highlighted
positions of found items are marked on scrollbar (light blue squares in middle)

https://cloud.githubusercontent.com/assets/2779184/8047500/7b405bbc-0e46-11e5-9146-114c7d939f11.png

All planned features are now implemented
(in some form :))
let the bughunt begin!
https://cloud.githubusercontent.com/assets/2779184/8068382/db13d0f2-0ef3-11e5-84ab-05fd7b1b55c5.png
Stash

Reworked scrolling, scrollbar thumb should now represent visible area.
newly added items  (import stashtab, import equip and crafting) now place green vertical marker to scrollbar.

Bookmarks

Bookmarks are now saved to persistent data
bookmark position can be changed by dragging marker in stash

Import
Stash tab JSON can be imported by Load button

new bookmark is created. Items that fit are directly added under bookmark with same order as in original stash tab: Items that not fit in stash width are added at bottom

When importing equip from menu, new bookmark is added and items are placed under it.

I think the ingame one doesn't actually do much more than doing a plaintext search vs the ctrl+c text of the items... Let me check.

Problem is we have no plaintext for item :/
We have Item (internal class) and Json (parsed in JObject)
I can probably save json to string and do fulltext
or use visitor and visit all JProperty nodes and do fulltext on them

If you want a quick and dirty way, just concatenate all properties with spaces. It's not like the game is trying to be intelligent with the search in any way.
It would probably be still nice to have the ability to ctrl+c an item like you can in the game and receive the same (or similar, things like "(unmet)" for stats on unusable items are pretty unnecessary) plaintext.

I found quick way to improve search:
Search is now searching in all attributes generated by code that fill "Item Attributes" (used separately on each item) and on all string fields from Item (flavour text, type and name).

There could be some performance problems with very big stash, but it should be enough at least as initial implementation.

Damn, it looks so nice! Haha I am out of town for the next few days, so I
am without a computer, when I get back I will definitely start it up.
On Jun 9, 2015 3:44 PM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

I found quick way to improve search:
Search is now searching in all attributes generated by code that fill
"Item Attributes" (used separately on each item) and on all string fields
from Item (flavour text, type and name).
[image: better_search]
https://cloud.githubusercontent.com/assets/2779184/8071331/3640ddfc-0f09-11e5-8309-45f35a3c130d.png
There could be some performance problems with very big stash, but it
should be enough at least as initial implementation.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-110525604.

Looks awsome, great work. You have to have spent a lot of time on this :)
But I came across a problem straight away:
When _persistentData.StashBookmarks is null in Window_Loaded and thus the program crash on line 153 in  MainWindow.xaml.cs. Here is the stacktrace.
System.ArgumentNullException was unhandled by user code
  HResult=-2147467261
  Message=Value cannot be null.
Parameter name: list
  Source=mscorlib
  ParamName=list
  StackTrace:
       at System.Collections.ObjectModel.Collection`1..ctor(IList`1 list)
       at System.Collections.ObjectModel.ObservableCollection`1..ctor(List`1 list)
       at POESKillTree.Views.MainWindow.Window_Loaded(Object sender, RoutedEventArgs e) in d:\PoESkillTree-ItemEditor\WPFSKillTree\Views\MainWindow.xaml.cs:line 153
       at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
       at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
       at MS.Internal.FrameworkObject.OnLoaded(RoutedEventArgs args)
       at System.Windows.BroadcastEventHelper.BroadcastEvent(DependencyObject root, RoutedEvent routedEvent)
       at System.Windows.BroadcastEventHelper.BroadcastLoadedEvent(Object root)
       at System.Windows.Media.MediaContext.FireLoadedPendingCallbacks()
       at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
       at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
       at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)
       at System.Windows.Interop.HwndTarget.OnResize()
       at System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
       at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
  InnerException:

@SpaceOgre sorry, I didn't try to run it clean for a while :). Its fixed now.

@Ttxman Np this is what testing is for :)
More stuff:
When maximizing the main window the newsize variable is set to Infinity and this causes a crash.

@SpaceOgre fixed ..
all your bugs were related to thumb size computation.
Scrollbar thumb size is computed by this crazy formula (according to documentation):
thumbSize = (viewportSize/(maximum–minimum+viewportSize))×trackLength

This make using scrollbar without scrollviewer really painfull

More testing:
When trying to drag-and-drop in the stash I get this error
System.ArgumentOutOfRangeException was unhandled by user code
  HResult=-2146233086
  Message=Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
  Source=mscorlib
  ParamName=index
  StackTrace:
       at System.Collections.Generic.List`1.get_Item(Int32 index)
       at MB.Algodat.RangeTreeNode`2..ctor(IEnumerable`1 items, IComparer`1 rangeComparer) in d:\PoESkillTree-ItemEditor\RangeTree\RangeTree\RangeTreeNode.cs:line 58
       at MB.Algodat.RangeTree`2.Rebuild() in d:\PoESkillTree-ItemEditor\RangeTree\RangeTree\RangeTree.cs:line 140
       at POESKillTree.Controls.Stash.items_CollectionChanged(Object sender, NotifyCollectionChangedEventArgs e) in d:\PoESkillTree-ItemEditor\WPFSKillTree\Controls\Stash.xaml.cs:line 115
       at System.Collections.ObjectModel.ObservableCollection`1.OnCollectionChanged(NotifyCollectionChangedEventArgs e)
       at System.Collections.ObjectModel.Collection`1.Remove(T item)
       at POESKillTree.Controls.Stash.gcontent_Drop(Object sender, DragEventArgs e) in d:\PoESkillTree-ItemEditor\WPFSKillTree\Controls\Stash.xaml.cs:line 724
       at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
       at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
       at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
       at System.Windows.OleDropTarget.RaiseDragEvent(RoutedEvent dragEvent, Int32 dragDropKeyStates, Int32& effects, DependencyObject target, Point targetPoint)
       at System.Windows.OleDropTarget.MS.Win32.UnsafeNativeMethods.IOleDropTarget.OleDrop(Object data, Int32 dragDropKeyStates, Int64 point, Int32& effects)
  InnerException:

I have some things I noticed about GUI stuff, nothing important and could come down to personal preferences. (This is just what I think and nothing else ;) )

When opening crafting window it would be nice if it was centered
The "Ok" button in the crafting window is a bit hard to find among all the other stuff. Maybe make it a tad bit bigger and change the placement.
The tier name and lvl for attributes should be shown straight away not just when using the slide.
Since I like stuff to be ordered I would like to see the same distance between the Equipment Button and the CRAFT button as the distance between the Pasive Tree and Equipment Button
Either all buttons should use CASE or none, just for cohesiveness.
Pasive Tree -> Passive Tree
Add a bit of a space between LOAD and searchbox

Update on search crash:
I though it was because I had a white item in stash but does not seems to be the case. Now I have only a yellow item in stash and item.Attributes is still null in ItemAttributes:LoadItem()

It was caused by newly crafted items. I forgotten to fill Mods and Affixes.
GUI:

craft window and bookmarr window are now centered
I should find different placement style for bookmark window
Yes something should be done with OK button, but I'm not sure what :)
maybe Big OK button spanning whole width of crafting window?
Tiers are now showed from start
I want to move CRAFT button somewhere to equipment tab, this is debug location :)
Is placement of  "Passsive Tree"/"Equipment" tab headers good?
all caps everywhere :), The tab headers should be restyled to differentiate between tabs and buttons
maybe something like stash bookmarks only horizontal?
PASSIVE TREE, done
The load button should be probably removed and integrated with MainMenu/Tools/"Download/Import Items", What do you think?

Known bugs:
"Total attributes" is not working
Inventory changes are not saved

Ok Button: Maybe like the MessageWindow that is used for Update etc. Button is placed down to the right and there is a different background for the bottom part.
Yes I like the placement of "Passsive Tree"/"Equipment"
Tab headers: Yeah something like the stash bookmarks might be nice, hard to say without testing.
I agree that the Load button should be integrated in the Import Items window

This one is fixed in upstream

Can anyone test how uniques interact with the stash? I wish I could play
with this lol
On Jun 10, 2015 8:33 AM, "l0g0sys"<EMAIL_ADDRESS>wrote:

This one is fixed in upstream
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-110798492.

@l0g0sys Merging item editor into current master wont be trivial :/
@EmmittJ what specificaly? It works just like any other item, only Image is wrong, because it is taken from item type.

There shouldn't be any problem merging it. All my recent additions are
pretty much transparent. Didn't change any existing interface/API.  You
might have maybe 1 or 2 conflicts and that's it.

I was just wondering since I don't think you can craft them. Just wondering
if they caused an error :p
On Jun 10, 2015 9:56 AM, "Ladislav Šeps"<EMAIL_ADDRESS>wrote:

@l0g0sys https://github.com/l0g0sys Merging item editor into current
master wont be trivial :/
@EmmittJ https://github.com/EmmittJ what specificaly? It works just
like any other item, only Image is wrong, because it is taken from item
type.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-110833216.

Github says I can auto merge so no conflicts.

@EmmittJ strange, "Can't automatically merge.": https://github.com/EmmittJ/PoESkillTree/compare/master...Ttxman:ItemEditor
@l0g0sys there is lots of conflicts, but i didn't look into them yet. I have changed lot of things related to UI, and they are conflicting mainly with your localization stuff :).

Yeah, if you changed elements which i localized there will be conflict :)

Ah, just switched to the desktop version of the site. The mobile site I guess always says you can auto merge >.>

@l0g0sys usually not the elements, but i have made large changes to main window structure. and you have added lot of elements, which confuses merge tools

I have switched merge tool to P4Merge (it helped a lot), and merged current master into item_editor branch.
Total attributes are now visible.

My first observations:

Those projects WpfRangeControls and RangeTree should be removed. And those few source files provided by them should be added directly to WPFSkillTree project. When someone downloads source with Download Zip method, it should be able to compile.
The mod name underneath the slider in crafting dialog is redundant and hard to read and makes hard to spot the thumb, so it should be removed as well.
The button styling should be same as rest of application as @SpaceOgre mentioned. So you use labels with proper casing for labels (in this app it's "Do Something Fancy"), and let styling do the rest.

I like concept of git submodules, It's useful, at least for development, you can add commits or pull new version of linked project without manually copying the changes to other repository. We can bundle complete source code with releases and keep the submodules. I think its not a problem, anyone capable of doing something with source code is able to clone from git.
if we would like to make github "download zip" compilable, the projects and source files should be left where they are (separate projects), just added to this git repository, instead of linking submodules.
what about  multimods? It can be made more readable, but I am against removing the mod names.
Buttons will be changed. (btw All the <Label>s in our source code should be <TextBlocks>, because they are used as TextBlocks: no complicated content, No access keys and targets)

I'm strongly against those submodules. I don't wanna see tens or hundreds of tiny projects poluting solution. It might be useful for certain types of projects, but in this one...no. Having separate project for each 2-4 files is just silly. It's completely unnecessary for this project and brings more complications and limitations than it helps with anything. You make separate project only when it outputs assembly, be it executable or DLL. Ee don't want to have 100 DLLs for each small class so there is no reason for such small projects at all.
Ah yeah. Hybrid mods need labels for each slider. Maybe add mod name above each slider for hybrid mods? And single mods doesn't require any.
Yeah. Label should be used only where label is required. For example atm. it's not possible to have version string to contain underscore because Version field (Label) in About dialog would eat that underscore as accelerator key determinator. But i guess, there is lot more of such small issues like improper use of certain elements.

Yeah I think a lot of elements might be used in the wrong way. Some if it is because I never have done WPF before and just tried stuff until something worked :)
Hopefully I will get some more free time soon so I can get in and do some coding for the project again.

Range tree and range controls have both decent size, compile into dll encapsulating specific function and are independent of PoeSkillTree. In case of range tree I am not even original author. These are all reasons to have it as separate projects. 100 DLLs is only esthetic problem, there is no performance hit and it actually speed up compilation.
There are lots of mods with multiple sliders, I don't like them behave differently from the others.

I agree with @l0g0sys that the name of the sliders can be hard to see, but I'm not sure how to change it.

If the name is moved above the slider it will take a lot more space but it will be easier to see the name.
Another option could be to have it only show on hover but that might not be as intuitive to the user.
Or it could be a toggle option for the user, so that people that are familiar with the crafting tool can just hide the names.

But like I said I don't think there is a perfect option for this.

The mod name color could be changed  to opaque color with better contrast hide on hover?

Not on hover. At some point we want to run this app with touch screens,
and there is no hover.

But it might work with onclick and hold on the slider, unless that would break something of course.

Opaque text color, bigger height and more contrast color of slider ( so thumb will be better visible) and hide text on hover or when dragging? But won't look very good :/
I tried a few different styles when i created crafting window and current one was best i could think of

Just imagine you have touch enabled device and you want use those
sliders with your finger. Imagine which portion of slider will be
covered by finger, etc. :)
Or just look how other applications handle it. Use UX designs which are
already in use for years, don't have to invent anything new :)

You don't need to make separate DLL to reuse code at all. The code
origin doesn't imply using separate project as well. There are multiple
classes already in project which are independent. You want separate
project for each of those? And i don't want to tell people, that they
have to create separate project for each independent
feature/class/whatever and then link it to main project to use it. Oh
and don't forget you have to manage build settings, versioning and
whatnot once it is separate project. You cannot reference just random
versions of assemblies.
You know what you should do instead? There is popular technique for such
situations, dated way before even C# existed. Create Contrib folder in
WPFSkillTree project and copy there your RangeTree folder and
WpfControlSomething with sources. Also don't  forget to copy LICENSE or
README which must be distributed together with portions of code under
most of open source licenses. And it will make life way easier for
developers than your submodules.

I like features that are reusable somewhere else separated from biger project.
for example, I think that your localization system should be standalone dll, but it is you choice as author.
I like using projects because i can debug into, modify them and push change to author without any additional effort. But if we won't use them, we should replace them Dlls or nuget packages.
git submodules are set to use specific commit, so no problem with incompatible versions. And we are using .NET and csproj projects (no makefile and need to support 5 different compilers) so no problems with building.

Yeah technique that originated before versioning systems and before big shared code repositories like github. I would do it for projects that are not on Github, but if you can directly link parts of your repository to original work it should be done. (with Git, each contributor have also independent local copy, so there is no problem when author removes original project)

That's all nice, but i like compact repositories. Where you click
Download Zip, extract content, double-click solution and hit F5.

I'm not gonna mess with git and repositories just to see someone's
progress in his repo/branch.

Githubs "Download ZIP" that excludes submodules is annoing. But git clone --recursive git://github.com/.... is not slower than downloading and extracting zip.
There is alternative to submodules called git subtree, that should help, but i haven't use it yet. I am comfortable with submodules, but if subtree helps i can probably start using it.

I'm trying to simplify every process connected to development and
release management, but this doesn't simplify anything for this project.
You don't use stuff just because it's trendy. You use stuff to make life
easier. These submodules are ment to be used when you need this
functionality of having multiple project repositories in sync. We don't
need this. When will you realize this? :)

I'm actually using both RangeTree and RangeControls in different projects (sadly not public) and I want to propagate bugfixes back. So i need to be in sync.

And that should be the reason for making stuff complicated and place
limits for rest of us and future developers of this project? :)
Do you really expect, that there will be so many bugfixes in those two
projects that it will be worth of solving it this way and our project
will benefit from it?
Ask yourself these questions :)

Yes it is perfectly worth to force other developers to run one more git command once in the while. And its is worth not just because it will ease my work a little. It's worth, because it simplifies code sharing and contributing your work back to community. It's worth because if you are using someone else code you should be prepared to contribute your changes back and plan your infrastructure accordingly. And its worth, because just reading this discussion will take more time that you will spent on submodules on this project per year (if you wont be doing pull requests on those projects)
With submodules i can make change, fix bug, push it, create pull request and be done. Without them i have to write bugreport, and let them fix it again or if I want to contribute my code, I have to redownload original repository, do manual merge, create patch and add patch to bugreport.
Where is the limit that project is too small to be worth to release it on github? What size project has to be to be worth contributing back? I don't know but I will gladly spent time needed to maintain the project infrastructure for any code i use.

Limit? Limit is that the project is active. RangeTree is not active at
all, there is no activity, doubt there is anything to do. And other one
you've just made 14 days ago.
This bordelines with harassment :)))
I like that idea about sharing and stuff, but you've picked wrong
projects to implement it on.

So they are not worth your effort, because range tree is completed and range controls are new. OK.
I have cleaned up the existing code for range panel, added rangescrollbar control and published it, because there is no other marked scrollbar library currently available. So i should just stuck it inside poeskilltree forever just because i wanted it for stash?

Not only my effort, everyone's else, because the chance that anyone else
will be doing something with those files is miniscule. We have limited
free time on our hands to fiddle with every component or library and
implement stuff which isn't even needed by this project, just to make
the component flourish so rest of the world can benefit from it.
And yes, once in a while, if EVER, you do change those files in this
project, you just copy them to your repo, if you are so keen on sharing
them with world.
That's it. And it won't impact anyone, any development process, any
GitHub site functionality, nothing.
And if ever, you do progress in your project directly and we will feel
that update is needed for whatever reason for this project, we will copy
those few files to this project.

I just want you to be realist and not to dream about stuff which won't
happen. And because of those dreams you will just impose limits or extra
workload for every contributor or anyone else interacting with project
in general.

Some more comments:

This window feels cramped, some space between elements would be nice. The Ok button feels to small, should probably be the same size as the Delete button.
And it would be great if it was possible to remove a currently equipped item without using the Del button on keyboard. Either drag away or maybe right click could work.

Sorry for delays, I am in middle of changing job so I have only little free time. I should be able to something today.
@l0g0sys we won't solve in this thread and it is ultimately decision of the person that will merge pull request.
For deleting items I am thinking about:
Overlay icons for delete and equip - but this will not work for small items like rings
Rightclick menu (this should be probably added anyway)
And Drag&drop trash-bin area - It seems like too much drag&drop when cleaning imported stashtabs and removing lots of items.
I like the rightclick for delete, but its pretty nonstandard and very confusing behaviour :/

Hehe, well, i'm one of those who can press Merge pull request too :)
That's why i'm already stating my opinion now.

Honestly I have no idea what you guys are arguing about, but I would like
to have this repo self reliant. They should be no reason that if another
developer wanted to start this project that they would be required to go to
another repo to get a dependency.
As for merging...this is going to be interesting. Has anyone checked the
amount of conflicts there are?
On Jun 25, 2015 6:56 AM, "l0g0sys"<EMAIL_ADDRESS>wrote:

Hehe, well, i'm one of those who can press Merge pull request too :)
That's why i'm already stating my opinion now.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/117#issuecomment-115265413.

Read this https://git-scm.com/book/en/v2/Git-Tools-Submodules
It's just all about @Ttxman misunderstanding the use of submodules. You use submodules to make development EASIER, and not just to share stuff. You use every technology/feature to make development easier, there is no point otherwise. In our project it's not making anything easier, rather causing complications, so  IMHO it's an inappropriate use of them here. There won't be any active development in those submodules for anyone to benefit from. Also, we might choose to completely change their implementation for our purposes and then all the sharing stuff goes away.
You use submodules when your application references larger third-party library, where you expect to be actively contributing to development of this library.
(think, this should be mentioned in GitHub article about submodules :)
In commercial products where stability is top issue, you cannot even use them. You can't just randomly pull changes from referenced repos and put your product at risk.
So, as you can see, there is place for them to be used, but there are cases where there is no benefit to either party, or you even cannot use them at all. You have to use them where appropriate.
Hope, this dispute will end soon :))
Regarding conflicts.
I know about one conflicting file and that's Updater, which i had to change to work with setup wizard installation. It still uses Raven.Json implementation which @Ttxman replaced with Newtonsoft.Json.
Rest should be already resolved few weeks ago.

@l0g0sys It's not about misunderstanding
I just think, that submodules are best way to reference 3rd party code, because you are actually referencing. If you just copy the code its similar to doing version control by saving project to zip file once in the while, it also works, but there are better ways to do it.
There are exactly two complications: (if you are not pushing to the 3rd party library)
1)You have to do initial clone with --recursive parameter to download referenced libraries
2)Github download zip feature does not contain the referenced code
These complication are for using the submodules feature and they not change or increase with more referenced repositories. For me the problems are very similar to repairing broken nugets after the clone.
I offered to look into switching submodules to subtrees, which should (probably) offer both local in-project copy of referenced project and possibility to push changes to original repository (or branch of original repository) without too much problems but it was lost in discussion.

If ever anything like this, than rather subtrees. Read this about problems with submodules https://makingsoftware.wordpress.com/2013/02/16/using-git-subtrees-for-repository-separation/.
But if this will end up in 10s of subtrees for each group of 4-5 classes (.cs files) with their own repositories, i'd like to see the one who's gonna be managing this. I won't.
I want to jump into project, do my work and i don't wanna deal with this stuff. I don't care if there is new progress in those subtree repos and i won't be checking 10s of them for new stuff. If everything works and there are no bug reports, then i won't be randomly merging new features which we have no use for or risk new bugs being brought in.
And i'm telling you again :) There is no "best way" how to do stuff, if you have multiple options each with its pros and cons. You simply pick the one which benefits you based on your needs. You are just wrongly assuming that this project need this and would benefit from this :))

But that's my humble opinion. If others want this “let's split it into tiny pieces and share them” stuff then I'm OK with it :)
I fortunately already gone thru this. I was the one bringing new techniques/methods into project, which were just making co-workers uncomfortable, and in the end they were not even used as how I imagined they would be. So, I've learned my lesson :)

Ok, so this is completed except conflicts correct?

Guess, it works to certain degree and i'd not mind pulling it in whatever state it is.
There was lot of refactoring done, and it's blocking me from working on pretty much anything as i'd just create more and more conflicts.
After checking https://github.com/Ttxman/PoESkillTree/tree/ItemEditor there is something wrong.
Not sure how upstream/master merge was done on that branch, but Tools folder has files missing.

Alright, well I will check this out tomorrow and see what happened. I really hate merging code. I feel like it will cause a lot of problems

I just spent two hours on trying to merge this. There aren't many conflicts but the ones that are there are a pain. Someone else will have to look into it because I am not sure I can get it done....

Sorry for delays :) I'll look into it it right now. (I have first free day in a month :/)

Is there a reason why we we referencing windows forms and using
System.Windows.Forms.Control.ModifierKeys.HasFlag(System.Windows.Forms.Keys.Shift)
in mainWindow.xaml.cs
instead of WPF Keyboard?
if (Keyboard.IsKeyDown(Key.LeftShift) || Keyboard.IsKeyDown(Key.RightShift))
in persistenddata
There is lot of stream.close() calls. Wouldn't be better to use using(var s = new ...){} construct?

private void ShowPoeUrlMessageAndAddToClipboard(string poeurl)
There is WPF class System.Windows.Clipboard that replaced the windows forms one

AppData.cs -  is there a reason for not using "XML Documentation Comments" format?

Think, you mean whole of project and not single file, right?
And ofc there is. Current documentation policy is "use comments where
you see it fits" :p

It is the only fully commented file in project (probably), It would be nice to show comments in intellisense.. :)

Yeah, i'm up for some standard source documentation policy.
If only that XML format wasn't so cluttered. M$ must be always different
than rest of the world.
If you know some good web page with guidlines other than MSDN let us know :)

Yeah they are cluttered, but visual studio really help with them. simply write /// instead of // and VS will insert empty XML comment with right format and prefiled attributes

Ok I've made bunch of changes:

merged master into ItemEditor branch (missing files should be back)
some restyling :

added delete to right click menu on items
added drag&drop delete

I will continue in few hours :)

stashtab import is now separate Tool menu item

I have restyled tab headers and moved craft button to equipment tab

I'm not entirely satisfied with "Craft new item" button, I'll try to make it better

I'll be without internet during the weekend. :/
Is there anything i forgotten to add/change?
btw @l0g0sys can i use "{l:Catalog Message='example text'}" instead of nested tags? There is lot of strings I'll need to change..

Nope, i did only nested tags for now.

"Nope, i did only nested tags for now." as in It is not compatible with translation logic? Because the markup extension should be same..

It is compatible. How do you think messages from XAML gets localized
then? :)
Not sure what you mean by markup should be same.
There is Localization.L10n class as centralized C# API and
Localization.XAML class as XAML extension which acts as proxy to L10n.

I don't know how it works :), that why i ask. (you could parse message position from xaml/baml or something)
Your "l:Catalog" class is derived from MarkupExtension, so it could be implicitly used In nested tags or in attribute value markup extension. I was confused, because you said it can't be used as {l:Catalog ...}
I have slightly modified your Catalog markup extension to work with default Content, this simplifies syntax a little..
instead of:
{l:Catalog Message='PASSIVE TREE'}
you can write
{l:Catalog 'PASSIVE TREE'}
or even
{l:Catalog PASSIVE TREE}
The main reason are annoying xaml warnings in when using textblocks :)
<TextBlock Margin="6,0" TextAlignment="Left" TextBlock.FontSize="16">
     <l:Catalog Message="Saved Builds"/> <!-- warning here "Inline expected" -->
</TextBlock>

It can be changed into
<TextBlock Margin="6,0" TextAlignment="Left" TextBlock.FontSize="16" Text="{l:Catalog 'Saved
Builds'}"/>
Without warning :)

Well it could not be used as property value as i wrote it.
I know there like 3 or 4 methods to make it work as property value
depending on features it should provide (binding one-way/two-way and
whatnot).
Did only quick look into it and it was way too much hassle on first
glance and even could be pick which method to use :)
So if <l:Catalog Message="message" /> can be written as
Property="{l:Catalog 'Message'}", then how can you define message with
context in that property form?
As tag it is <l:Catalog Message="message" Context="context" />
Btw, if we gonna use this property form, XAMLText tool must have such
form implemented, which doesn't have obviously atm. Otherwise those
message won't get extracted from XAML files.

{l:Catalog Message='message', Context='context'}
{l:Catalog 'message', Context='context'}
It behaves same as Path in property {Binding }

Did only quick look into it and it was way too much hassle on first glance and even could be pick which method to use :)

MarkupExtension that you wrote could be directly, without any modifications, used as {l:Catalog Message='message', Context='context'}. The hassle with bindings actually starts if you want to bind something into the some property on Catalog class, for one way bindings you don't have to do anything special.

Btw, if we gonna use this property form, XAMLText tool must have such form implemented, which doesn't have obviously atm. Otherwise those message won't get extracted from XAML files."

This is the reason why i asked if it could be used, and you said the format is compatible with translation logic :/ ....
I am not on my main computer right now, but when i get there i will switch back to nested tags format..
btw with Content property attribute you can now also use
<l:Catalog>message</Catalog>

While nested tag form is bit more code to write, it also provides best
readable form, because property names match arguments of L10n class
methods. You cannot make mistake here what's going on.
And tbh, i don't like when you can write one thing by multiple ways.
If you work in team and everyone uses his own favorite way, it creates
quite hard to read code. Specially when some new people don't know all
the possible ways.
This is reason why i don't like Perl language :)

This thing ready to be merged? I would like to get a release out within the
next couple days :)

Looking through it looks like this is ready to go. I will merge it and we can see if we need to make changes later :P


Test PR

CI Build Link:
http://sou-jenkins2.swinfra.net:8080/job/FileAnalysisSuite/job/FileAnalysisSuite~adapter-filesystem~test~CI

This PR was updated by the PollForGitHubNotifications

This PR was updated by the poll job


Remove CpuInfo

We aren't using cpu_name or egl_info anywhere in the dashboard or the backend, so it makes sense to stop collecting them.

Nice. Does this allow us to further detail the loading of the native binaries until we install the signal handler?

@bidetofevil probably, but I'll wait for the NDK refactor to review the loading


Correct documentation for limit parameter of steem.account.Account.ge…

…t_account_history

The end index is 1 less than the number of items we are interested in. The documentation incorrectly describes the limit parameter as an index when it is not an index.
Docs changed to be verbatim the same as the method that this method delegates to.


Support generation of single index for multiple checklistbank datasets

As an example, WoRMS is registered as multiple datasets in checklistbank.
We need to produce a single index/docker container combining these datasets.

WoRMS does exist as a single dataset in CLB. The other ones are parts of WoRMS used by COL and we are trying to get away from that model and use the single dataset instead. I am not aware of any split datasets that we would need to combine. Without a single dataset key (int or UUID) it would be difficult to identify what the service is matching against.

thanks @mdoering . Possibly nothing to do here then.


Add jump search in JavaScript

Add jump search in JavaScript programming language .

can i work on this issue??

i can work on this issue. Please assign this task to me


Fix for TF v1.14.0-rc0

Fixes #526
Previously, we were using unique_layer_name from tf.keras.engine.base_layer_utils, however in TensorFlow >1.13.0 this function was renamed to unique_object_name and moved to tf.keras.backend.py.  I've copied the function logic over, since it luckily only relies on common Python libraries and public TensorFlow functions (specifically, tf.get_default_graph()).

@jvmancuso, looks great. If @mortendahl is ok I think., we can approve it.
I have re-run the pysyft notebooks with this fix installed and TF 1.14.0-rc and it works.
However I have noticed that I am getting the insecure randomness warning with this version of TF #513
WARNING: Logging before flag parsing goes to stderr.
W0605 12:49:04.146198<PHONE_NUMBER> secure_random.py:22] Falling back to insecure randomness since the required custom op could not be found for the installed version of TensorFlow (1.14.0-rc0). Fix this by compiling custom ops.

Yep there is work we need to do to be able to support other versions of tensorflow for secure numbers.

Cool, tagging #513 so there's a link back to this note in the relevant open issue

it looks good, but one question: what are they doing in tf.keras if this function is gone? are we, or should we, be doing the same instead of using this older behaviour?

The behavior is identical: the only thing that's changed is the function name and it's location insider the TF codebase


[SVC-2367] Remove salt-key for deleted servers

When we delete a server, salt apply fails because the server is no longer reachable
Add a null_resource with a shell script in pools that calls salt-key -D on any servers not present in Terraform

Use triggers to automatically calls this when the servers change

From SyncLinear.com | SVC-2367

Right direction.
You'll probably need something weird like:
salt-key -L | grep -v "${join(keys(var.servers), "|")}" | xargs -L 1 salt-key -d

Make sure to add a depends_on = [ module.server ]

Sorry I won't be able to vc until ~6, but am i going in the right direction with this?

ping me whenever and i'll jump on asap

@NathanFlurry do you have time to do a huddle tomorrow after ~11?

i'll probably be at a cafe since I'm visiting fam in mountain view, but yeah

@maxknerrichmckenzie This one is probably going to be tricky since it brings in a lot of new concepts with Terraform, etc all at the same time. I can jump on a huddle and talk it over if it helps.
It should be a good intro to the inner workings of our Terraform stuff though

Getting this error when trying to run:
╷
│ Error: Incorrect attribute value type
│
│   on server_gc.tf line 6, in resource "null_resource" "server_gc":
│    6:         triggers = {
│    7:                 servers = var.servers
│    8:         }
│     ├────────────────
│     │ var.servers is a map of object
│
│ Inappropriate value for attribute "triggers": element "servers": string required.
╵
╷
│ Error: Unsupported argument
│
│   on server_gc.tf line 10, in resource "null_resource" "server_gc":
│   10:         master_host = var.deploy_method_cluster ? data.terraform_remote_state.master_cluster[0].outputs.salt_master_host : null
│
│ An argument named "master_host" is not expected here.
╵
╷
│ Error: Invalid function argument
│
│   on server_gc.tf line 14, in resource "null_resource" "server_gc":
│   14:                 command = "salt-key -L | grep -v ':' | grep -vx \"${join(keys(var.servers), "\\|")}\" | xargs -L 1 salt-key -d"
│     ├────────────────
│     │ while calling join(separator, lists...)
│     │ var.servers is a map of object
│
│ Invalid value for "separator" parameter: string required.
╵
╷
│ Error: Invalid function argument
│
│   on server_gc.tf line 14, in resource "null_resource" "server_gc":
│   14:                 command = "salt-key -L | grep -v ':' | grep -vx \"${join(keys(var.servers), "\\|")}\" | xargs -L 1 salt-key -d"
│     ├────────────────
│     │ while calling join(separator, lists...)
│
│ Invalid value for "lists" parameter: list of string required.
╵


Replace python-based API stub

Problem
Currently, there's a python-based API stub that contains some hard coded results for the UI to work. This was to get around the backend server not being easily stood up due to many environment variables as "inputs" (the inputs problem and server startup is being solve in issue ansible/azure-aap-deployment-driver#21).
Solution
Use backend server for running the solution and remove the sub.

The stubbed API primarily serves as a hard-coded result set for the /step path which is registered, here, in server.

The implementation will need to have the following elements:

Support runtime environment values: development | production
Delete the API stub found in ./ui in favor of using server, whether in development or production
Migrate all stubbed test data hard coded in ./ui/run.py into ./server

Implementation

Add an additional environment variable of APP_ENV. See server/config/environment.go on examples of reading in a value using the go-envs library

Runtime Environment - development | production
To support defining a runtime environment, an environment variable is introduced.

Modify server/config/environment.go, adding ENVIRONMENT_NAME to envVars.

Valid values are: development | production
Default value: production (this is to avoid breaking changes since we're adding another execution path if development)

environment variable ENVIRONMENT_NAME
Support setting of a flag -environment

Example: `./server -environment development'
If flag value is present, it should override any environment variable set, otherwise, default to environment variable value

Seed data
Using the structs defined in server/model/model.go, add an additional file to the model package, seed_development.go. Here, translate what's in the python stub API as hard-coded JSON / string literal into Go code. Have a "public" (to the package) function that accepts a *persistence.Database as an argument, seeding that instance with data.

The function defined in seed_development.go will be used in main depending on the runtime environment.

Startup changes
Modify server/main.go with a private function getDatabase that replaces the call being used to just new up a database. The gist of this function's body is  conditional checking of the environment to determine whether to start up:

development: an in memory database and seed it
production: call and return the same call that's there now to get a new database

Deletion of the python API
Once the changes to the server are implemented, the full removal of the Python API will still need to wait until the server can start up easily, which will be completed in issue ansible/azure-aap-deployment-driver#21.

Whether to delete the stub API or not as part of this work, check with @kevinhillinger who is working on ansible/azure-aap-deployment-driver#21. If this work hasn't been merged in, the stub API should remain temporarily.

Thanks for the detailed write-up. Reviewing now.

Whether to delete the stub API or not as part of this work, check with @kevinhillinger who is working on #21. If this work hasn't been merged in, the stub API should remain temporarily.

Makes sense!

Completed the runtime flag: https://github.com/kevinmgates/azure-aap-deployment-driver/commit/ad333023767b2624e82684ade80c2de752e1621c

Closing. @bobjac created script and provided offline from the repo, first week of may


Receiver Close() times out due to block in receive

I am using this package through the https://github.com/Azure/azure-event-hubs-go SDK to continuously receive messages from an event hub.
When the system experiences extreme load and/or occasional network instability, calls to Close() on an individual Event Hubs receiver (and by extension, its underlying receiver/link from this package) have a tendency to hang until the provided context expires. My typical context timeout is 10 seconds, but I've observed the same with much longer timeouts (it doesn't appear to be related to time).
I recently captured a goroutine dump of a process that was encountering this problem and observed that each timed out Close() was causing an extra goroutine to be left dangling indefinitely (along with the full prefetch buffer for the associated link). These are the relevant groups of leaky goroutines:
1522 @ 0x43ab25 0x4059fa 0x405755 0xa70197 0xa70df8 0xa6f47f 0x4717c1
#	0xa70196	github.com/Azure/go-amqp.(*link).muxReceive+0x276	/go/pkg/mod/github.com/!azure/go-amqp@v0.13.4/link.go:513
#	0xa70df7	github.com/Azure/go-amqp.(*link).muxHandleFrame+0x117	/go/pkg/mod/github.com/!azure/go-amqp@v0.13.4/link.go:548
#	0xa6f47e	github.com/Azure/go-amqp.(*link).mux+0x37e		/go/pkg/mod/github.com/!azure/go-amqp@v0.13.4/link.go:304

386 @ 0x43ab25 0x4059fa 0x405755 0xa70197 0xa70df8 0xa6fe35 0xa6f2d6 0x4717c1
#	0xa70196	github.com/Azure/go-amqp.(*link).muxReceive+0x276	/go/pkg/mod/github.com/!azure/go-amqp@v0.13.4/link.go:513
#	0xa70df7	github.com/Azure/go-amqp.(*link).muxHandleFrame+0x117	/go/pkg/mod/github.com/!azure/go-amqp@v0.13.4/link.go:548
#	0xa6fe34	github.com/Azure/go-amqp.(*link).muxFlow+0x234		/go/pkg/mod/github.com/!azure/go-amqp@v0.13.4/link.go:380
#	0xa6f2d5	github.com/Azure/go-amqp.(*link).mux+0x1d5		/go/pkg/mod/github.com/!azure/go-amqp@v0.13.4/link.go:290

When inspecting the source for the version I'm using (0.13.4), the line where those goroutines are hung is the last line of this block:
https://github.com/Azure/go-amqp/blob/2957005aeaa725796bbd4ae84de0dd5bf58d5fa7/link.go#L510-L513
As the comment mentions, the code is designed never to block here (due to the channel being buffered for the exact number of messages in the link credit), but something is clearly violating that assumption.
I'm not sure whether the issue is a protocol violation by Event Hubs w.r.t. link credit or a bug causing extra messages to be buffered in the channel. Either way, it seems dangerous to assume that everything will be perfectly well-behaved all the time. It seems like a simple select to handle the shutdown case would solve the problem here. Happy to send a PR if it seems like a reasonable change.

It would be interesting if you could get a snapshot of goroutines when Close() hangs (I assume there were others than what was pasted).  Based on the provided info, I believe the hang is coming from the call to c.getErr() while closing the connection.  This will block until conn.mux() exits which should be in progress now that c.closeMux has been closed.

Also, if you have a repro that would be reasonable for me to run I'm happy to take a look.

Fixed in post-v0.17.0


Error in render the images.

CharacterGen/render_script/three-js# npm run dev
npm ERR! Missing script: "dev"
npm ERR!
npm ERR! To see a list of scripts, run:
npm ERR!   npm run
npm ERR! A complete log of this run can be found in:
May dev file not be uploaded?

I will check tomorrow for this mistake, I may missed uploading the vite project's file

I will check tomorrow for this mistake, I may missed uploading the vite project's file

Any updates?

I have the same problem.


Escaping markdown in the PyPi embed.

Removes the possibility of markdown being rendered within an embed for the PyPi command.
Before:

After:

You saw nothing.

Coverage increased (+0.003%) to 56.602% when pulling f14c391e3a1228953cda29be7993c9a5ec51ca6f on pypi-command-escape-markdown into fc8e1e9b55a6134b5f5835b67127519d57f096df on master.


Questions about loadSize

Hi, thanks for your work again!
I have some questions about loadSize, the rgb and depth image first resize to loadSize (192, 640) before feeding in the network.
scale_transform = transforms.Compose([transforms.Resize(self.size, Image.BICUBIC)])
img1 = scale_transform(img1)              ## RGB image

And resize to original size after network.
pred_depth = torch.nn.functional.interpolate(pred_depth[-1], size=[depth_.size(1),depth_.size(2)], mode='bilinear',align_corners=True)
I want to know why you downsample the image from (375, 1242) to (192, 640)? Is it just to reduce GPU memory?  Will it cause performance degradation due to loss of information?

On the one hand, reducing the image resolution is due to the limitation of GPU memory, on the other hand, for fair comparison with other methods, we follow the previous domain adaptation methods (T2Net/GASDA) to process the dataset. If you increase the image resolution, performance may be further improved.

Thanks for your reply!


Not able to import flash as transformer.spec is returning None

🐛 Bug

I am trying to complete a summarization project and decided to use flash for it but am getting import error as transformers.__spec__  is returning None. I have opened huggingface/transformers#12904  issue on transformers page meanwhile, would like to know if there's a possible workaround to it.
Code sample

import transformers
print(transformers.__version__)
print(transformers.__spec__)

import flash

OUTPUT:
4.8.2
None
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-1-d02f1c770adc> in <module>
      3 print(transformers.__spec__)
      4
----> 5 import flash

/opt/conda/lib/python3.7/site-packages/flash/__init__.py in <module>
     16
     17 from flash.__about__ import *  # noqa: F401 F403
---> 18 from flash.core.utilities.imports import _TORCH_AVAILABLE
     19
     20 if _TORCH_AVAILABLE:

/opt/conda/lib/python3.7/site-packages/flash/core/utilities/imports.py in <module>
     75 _PYTORCHVIDEO_AVAILABLE = _module_available("pytorchvideo")
     76 _MATPLOTLIB_AVAILABLE = _module_available("matplotlib")
---> 77 _TRANSFORMERS_AVAILABLE = _module_available("transformers")
     78 _PYSTICHE_AVAILABLE = _module_available("pystiche")
     79 _FIFTYONE_AVAILABLE = _module_available("fiftyone")

/opt/conda/lib/python3.7/site-packages/flash/core/utilities/imports.py in _module_available(module_path)
     36     """
     37     try:
---> 38         return find_spec(module_path) is not None
     39     except AttributeError:
     40         # Python 3.6

/opt/conda/lib/python3.7/importlib/util.py in find_spec(name, package)
    112         else:
    113             if spec is None:
--> 114                 raise ValueError('{}.__spec__ is None'.format(name))
    115             return spec
    116

ValueError: transformers.__spec__ is None

Expected behavior

Able to import flash
Environment

PyTorch Version (e.g., 1.0):  3.7.0/3.8.1
OS (e.g., Linux):
Platform: Colab/Kaggle
How you installed PyTorch (conda, pip, source):
Build command you used (if compiling from source):
Python version:
CUDA/cuDNN version:
GPU models and configuration:
Any other relevant information:

Additional context

Hi @prikmm, thanks for reporting this. I've just added something to catch the error so hopefully it shouldn't break any more. Could you try installing from github with:
pip install git+https://github.com/PytorchLightning/lightning-flash.git@master

Let me know if that fixes the issue :smiley:


Display event id in the ui

Is it a ?

[ ] Bug Report

[x] Feature Request

[ ] Chore

Bug Report
Actual Behaviour
No information regarding the event id which might be very useful when accessing api endpoints.
Expected Behaviour
Event id should be made visible to the user
Would you like to work on the issue?
Yes

@iamareebjamal i think it is needed, what do you think.

No, that is not something users need to concern themselves with


AggregateUDF expression API design

File an issue to track the design of UDAF API
Perhaps something like
// form `FIRST_VALUE(a ORDER BY b)`
let agg_expr = AggregateUDF::call(first_value())
  .args(col("a"))
  .order_by(vec![col("b"))
  .build()?;

Originally posted by @alamb in https://github.com/apache/datafusion/pull/10492#discussion_r1599967446

related to https://github.com/apache/datafusion/issues/6747 (for window APIs)

https://github.com/apache/datafusion/pull/10560 is looking sweet to me


Use dns-sd for service discovery

This PR removes the dependency on iTunes by using dns-sd to discover airplay devices. Thanks for the inspiration pstadler regarding non-terminating bash processes

Closes #2. Thank you!


Support for Parameters with complex values

What is the expected enhancement?
Parameters are now used in schedules. Schedules have pulses which may have complex amplitudes. I'd like to be able to do this:
from qiskit import pulse
from qiskit.circuit import Parameter

amp = Parameter('amp')
sched = pulse.Schedule()
sched += pulse.Play(pulse.Gaussian(duration=128, sigma=16, amp=amp),
                    pulse.DriveChannel(0))
sched.assign_parameters({amp: 0.2j})

Hey! I'd like to work on this.

Excellent, @paniash! I've assigned. Please feel free to ask about any questions you may have 😄 .

Thanks a lot! Will do! :)

Just wanted to clarify something. Currently pulse supports parameters but only real ones. The enhancement is supposed to introduce complex amplitudes as well. Am I right?

@taalexander Just wanted to clarify something. In the current master branch, pulse supports pulse.Schedule.assign_parameters() but only real amplitudes. The enhancement is to include complex amplitudes as well. Am I right?

Hey! Is this issue open? Can I check this out?

@Arijit02 Hey! Thanks for your interest but I'm currently working on it. :)

Okay, fine.

@paniash, the changes will mostly be in circuit/parameterexpression.py. There will likely be a couple changes required in pulse/ once complex values are supported, but that can be done separately. If you run the short snippet from the description, I believe the error is raised in _raise_if_passed_non_real_value in ParameterExpression

This will also allow us to do things like this
beta = Parameter('β')
1.0j*beta

correct?

I actually implemented this before for personal use but never opened a PR because I couldn't find a use-case for it. @paniash looking at the early stage of your PR it might be best if I open one and you can help contribute if there's something left, what do you think? 😄
Complex parameters should also include some validation to not end up with expressions such as RY(0.2j) which will crash the execution.

@Cryoris I'd be glad! Given my knowledge of python, I don't want to be a bottleneck to merge this PR, so by all means, I'd be willing to contribute to your PR.
P.S. Should I close my PR then? Maybe @lcapelluto could confirm.


feat(hbase): Add dependencies for ABFS and ADLS

Description
Add hadoop-azure.jar to the lib directory to support the Azure Blob Filesystem and the Azure Data Lake Storage.
required by stackabletech/hbase-operator#539
Definition of Done Checklist

Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
Please make sure all these things are done and tick the boxes

- [x] Changes are OpenShift compatible
- [x] All added packages (via microdnf or otherwise) have a comment on why they are added
- [x] Add an entry to the CHANGELOG.md file
- [x] Integration tests ran successfully

TIP: Running integration tests with a new product image
The image can be built and uploaded to the kind cluster with the following commands:
bake --product <product> --image-version <stackable-image-version>
kind load docker-image <image-tagged-with-the-major-version> --name=<name-of-your-test-cluster>

See the output of bake to retrieve the image tag for <image-tagged-with-the-major-version>.

Do you think this "feature" is release noth worthy?

Do you think this "feature" is release noth worthy?

Yes, I would think so. For customers using Azure, it could be important to know that this works.

In that case: Would you mind adding a small snippet that we can add to the releas notes (either as a comment or edit the description)?

Would you mind adding a small snippet that we can add to the releas notes (either as a comment or edit the description)?

Product features

Apache HBase: The hadoop-azure module was added to the image and is contained in the classpath. This makes it possible to use the Azure Data Lake Storage Gen2 (ADLS) instead of HDFS. See the usage guide for detailed information.