How to specify transitive dependency version?

What version of Go (go version) and dep (git describe --tags) are you using?
go version go1.9 darwin/amd64
Problem
This is my first try using dep so please excuse any noob mistakes/assumptions.
First, I ran dep init, which vendored a ton of dependencies. One of them was a private dependency at Segment that imports github.comsegmentio/stats. Dep selected release 3.1.0 of stats even though this was incompatible with the private dependency, and the latest compatible version was HEAD of master.
The Gopkg.toml contained the private package that was directly required but not the transitive dependency, segmentio/stats. I added a constraint for segmentio/stats in attempt to fetch HEAD.
[[constraint]]
  name = "github.com/segmentio/stats"
  revision = "622a972a1a43d1f77454487e8d5be9b10b978132"

I ran dep status hoping to see reports of a mismatched dependency, but instead, it just had 622a972a1a43d1f77454487e8d5be9b10b978132 listed as the constraint and newest version but not 3.1.0 as the one installed.
Hacky Solution
I suspected that this may be because my segmentio/stats is a transitive dependency, not directly imported by my app. After importing _ "github.com/segmentio/stats" (unnecessarily) in my app, dep status asked me to run dep ensure, and the issue went away.
Question
What's the recommended way to select transitive dependency versions?

If you absolutely must specify the version used by a transitive dependency, you can add an [[override]] to your Gopkg.toml.


remove all  usage

The NuttX c++ library is incomplete, let's avoid including until we have a real standard library in place.
ecl: https://github.com/PX4/ecl/pull/672
GpsDrivers: https://github.com/PX4/GpsDrivers/pull/48

So what's actually the difference between std::round and roundf?

In NuttX cmath we don't have the overloads, so it was always the double precision version (round).

In NuttX cmath we don't have the overloads, so it was always the double precision version (round).

Oh nasty, good catch!


The inference Image is blurry，not as clear as example

Hi，thanks for openning HAT repository, the test info as follows:
pretrain model: Real_HAT_GAN_sharper.pth
test_yml: HAT_GAN_Real_SRx4.yml
I don't know where the configuration is wrong?

such like this


brew install fails

The install via brew fails with the following on Sierra 10.12.6
==> python -c import setuptools... --no-user-cfg install --prefix=/tmp/chirp--homebrew-virtualenv-20170828-67100-xs4adb/target --sin
Last 15 lines from /Users/klrice/Library/Logs/Homebrew/chirp/01.python:
--no-user-cfg
install
--prefix=/tmp/chirp--homebrew-virtualenv-20170828-67100-xs4adb/target
--single-version-externally-managed
--record=installed.txt
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/site-packages/setuptools/init.py", line 10, in
from setuptools.extern.six.moves import filter, map
File "/usr/local/lib/python2.7/site-packages/setuptools/setuptools/init.py", line 160, in
monkey.patch_all()
File "/usr/local/lib/python2.7/site-packages/setuptools/setuptools/monkey.py", line 48, in patch_all
distutils.core.Command = setuptools.Command
AttributeError: 'module' object has no attribute 'Command'

Hmm! I'll try this when I get home tonight to make sure it still works for me. Can you share the output of brew doctor?

I couldn't reproduce this, sorry.


The group_by_keys function in tariterators.py

I am not able to understand the logic of the code
"
if suffix in current_sample:
raise ValueError(f"{fname}: duplicate file name in tar file  {suffix} {current_sample.keys()})
"
in the group_by_keys function in file tariterators.py.
In particular, in my applications sometimes it works well, and sometimes it throws this error. I found that when we are running this iterator we are in fact actively adding keys and values to the dictionary, and one of the keys we added is in fact the suffix, so naturally, it should appear in current_sample. I am not sure why this should be an error, and how to actually fix this. Any help/comment would be greatly appreciated. Many thanks!

Can you attach the output of tar tvf shard.tar please?
This error is triggered when you have a file that contains repeated file names, something like:
dir/base.jpg
dir/base.json
dir/base.jpg

Such files are valid tar files (the contents of the latter file overrides those of the first occurrence), but for WebDataset, we consider them an error.

Actually, each of my tar files only contains a single image, and they share the same name across different tar files. When my input urls contain all the tar files, it throws this error. Is it expected?

Yes, that will trigger this error. File names are supposed to be distinct in WebDataset files; that's just a very useful convention, and it is needed to segment tar files into samples.
You do have an option of addressing this by using the explicit pipeline construction. Something like the following might work:
# warning: untested code

def my_tarfile_to_samples(src):
    streams = url_opener(src, handler=handler)
    files = tar_file_expander(streams, handler=handler)
    count = 0
    for file in files:
        fname, value = filesample["fname"], filesample["data"]
        _, ext = os.path.splitext(fname)
        yield {
            "__key__": str(count),
            ext: value
        }

dataset = wds.DataPipeline(
    wds.SimpleShardList(url),
    wds.shuffle(100),
    wds.split_by_worker,
    my_tarfile_to_samples(),
    wds.shuffle(1000),
    wds.decode("torchrgb"),
    get_patches,  # note that can put iterator->iterator functions into the pipeline directly
    wds.shuffle(10000),
    wds.to_tuple("jpg;png;jpeg"),
    wds.batched(16)
)

However, I strongly recommend giving samples unique basenames. Ultimately, the view of WebDataset-style files is that you ought to be able to take all tar files and extract them somewhere and end up with a reasonable file-based representation of dataset.

This issue isn't resolved and should be re-opened. @EEthinker is correct that group_by_keys takes in the handler as an argument, but does not use it at all. Therefore the ValueError is always thrown when a duplicate is found, regardless of whether the warn_and_continue handler is provided as an argument. I hit this error a bit recently so looked into the code details. I could create a PR with a fix if you like, some time in the next few weeks.

I have added a rename_files option that allows you to rename files from the tar file prior to grouping by the grou_by_keys function. There is also a select_files argument that lets you skip files during tarfile reading, giving you speedups for skipping unused data when reading from local disk.
The ValueError is always thrown, but it is also always caught. The handler function is called in the exception handler.

@tmbdev I found that the same error will raised when I read many tar files and each one only have one single video/image.  If I merge those videos/images into tars which includes ~100 files per one,  the error is disappeared. Maybe there should be some test for such case (many tars and each one only includes one file).

File names inside tar files must be unique across .tar files. That's because webdataset considers the entire collection of tar files to be the dataset and requires unique file names across it.
WebDataset notices non unique file names when you happen to shuffle shards in such a way that two tar files containing identical file names happen to end up next to each other.
When you put all files into a single tar file, the shard shuffle won't shuffle the files, so if you happen to have picked an order in which identical dinners are not next to one another, so won't get this error.
We could consider tar file boundaries to be sample boundaries, but having duplicate keys still causes problems elsewhere, e.g. with sample caching.
You can find duplicates using tar tf shards-*.tar | sort | uniq -d

@tmbdev I've opened #327 proposing a change that I suppose solves this problem in a harmless way - at least it did for my specific use case.

I think I've seen this error when I had one shard containing just a single sample (in two files) and I was doing infinite reshuffling. I think it randomly reselected the same shard twice in a row and ended up throwing this error despite all the file names being unique.
Tomorrow I'l try to reproduce this with a dataset containing a single sample in a single shard – it should fail every time.

I met the same issue today. If each of my tar files contain only one sample, with resampled=True, I got "ValueError: ("27dd4da69e_000071.caption.txt: duplicate file name in tar file caption.txt dict_keys([...])", None, None)". The error would have gone if I set resampled=False or make each tar file contains at least two samples.


Upgrade to v5.30.x

Do we know when the new Kusama ledger update will be finished? thanks

Its not working on Ledger. Please sort the issue or give us a heads up on the timeframe ?

Thank you for your hard work

Is it possible to make a transaction with the ledger nano again? It does not work for me.

When will this be on Ledger Live please? can anyone help?


Add support for generic mraa boards

Added support for generic board supported by mraa library
Signed-off-by: Nicola Lunghi<EMAIL_ADDRESS>

Any news? hey

Anyone here? hello?

Any chance to get an update on this?

Thanks adafruit because you consider a lot the pull request of other user (irony)


cluster: fix oversights

Hello @sunheehnus, thanks! All fine except for:
+        sdsfree(info);

the addReplySds() and addReplyBulkSds() functions automatically free the passed value, since it is more  efficient: sometimes we avoid copying this way.

Opps, the wrong addition should be a real oversight while trying to fix oversight. :-)
Thanks very much @antirez . Already fixed in the new commit. :-)

Thanks! Merged.


feat: use chalk-like colors on nix

a single-topic PR this time, does what it says in the title:
use chalk-like colors in the nix scripts' console log messages.

let's clean up that history first though.


Saving idfs and layer+time support

In GitLab by @JoerivanEngelen on Mar 9, 2018, 14:57
I think we have to reconsider some things in the idf.save() function

If I'm saving an idf I prefer not having to worry about composing a filename myself.
Since the restructure, figuring out the extension is unnecessary, as idf.save() creates .idf's and ipf.save() creates .ipf's.
So I think the util.decompose step became a bit obsolete.

Also I think the way imodpython currently handles saving multiple layers (with a groupby function), does not work for times and layers, due to this 3 year standing issue in xarray that will likely not be fixed in the coming year:
https://github.com/pydata/xarray/issues/324
So we have to think of an alternative here.

In GitLab by @Huite on Mar 13, 2019, 18:52
Fixed a long time ago. Closing.


Report syntax error messages

It would be nice to report the error message and its line when the file being checked has a syntax error. So, instead of just this:
Checking d:\run.lua Syntax error

We get something like what we have with luac
luac: d:\run.lua:11: '=' expected near 'foo'

I use luacheck with ST3. More than often, I make a syntax error and luacheck stops parsing the file I'm working on. Since I have no indication, I have no idea something is broken somewhere.
Thanks in advance!

I agree that this would be nice. I'll look into implementing this in another version but IMO this is not critical as there are already syntax-checking linters for Lua using luac -p for most editors, e.g. https://github.com/SublimeLinter/SublimeLinter-lua for ST3. So, it should be possible to configure it to run both luac -p and luacheck, or maybe installing them both is enough.

Oh, I see. I thought it was a matter of just calling loadstring somewhere and dealing with that before starting to parse. But yeah, installing SublimeLinter-lua did the trick.
Thanks! (Feel free to close this if you want).

It is not that simple because of forward-compatibility, e.g. it should be possible to check Lua 5.3 code using bit operators while running on Lua 5.1. loadstring would then panic on a bit operator while an actual syntax error is still ahead. So, I would have to actually put some error reporting logic into the custom parser luacheck uses.

To be fixed in next version.

Fixed on master branch.

Thank you. Works great


AWESOME pr

@zoltankiss  Are you able to turn all of these commits into just one? Also I don't think that space is required there.


InstagramBasicDisplay Adding thumbnail_url and updated description of fields

Added the thumbnail_url field and updated the description of fields.

[[certify-connector]]

Hello @reshmee011 ,
I hope you are doing well.
Congratulations, your pull request is approved. We will move forward with the certification process. We are preparing your connector for production deployment and will queue up for the next deployment schedule. Once your connector onboards the next deployment schedule, it starts to deploy your connector in our production environments that typically takes 3-4 weeks.
Please let us know if you have any questions.
Thank you very much for working with us.

Thank you @Amjed-Ayoub for approving the pull request.

Hello @reshmee011 ,
I hope you are doing well.
Your connector is in production deployment and queued up for the next deployment schedule. This process typically takes 3-4 weeks. Please note that the documentation for your connector will not be generated until the deployment process is in the final steps.
Please let us know if you have any questions.
Thank you very much for working with us.


How I can install and test this plugin?

How I can install and test this plugin? There is no way to install it, am I right?

There's no good way to install the plugin currently because it's not finished yet — I'll try my best to make it available as soon as possible

@cogscides

How I can install and test this plugin? There is no way to install it, am I right?

Good news: the plugin is now part of the Obsidian Community Plugins!
https://obsidian.md/plugins?search=sync graph
You can now install the plugin through Obsidian as any other plugin


Remove Guitar

Hello, I'm new to this world of mixing.
Is there any way, through this software, to remove just the guitar from a song?
I know how to remove the battery.
But I would like to learn how to remove the guitar.
Can anyone with any advice help me and help the community?
Thanks.

Thank you very much! It worked!


spectrometer abstraction

All shared code should be moved into parent class.

Looks like the skeleton is in place, but is not filled to completion

Exactly. The MicroHR does more work than it should.

Still the case? @untzag

Closing as these kinds of abstractions are moving to yaqd


fix(connlib): send dns proxy ips even with overlapping internet resource

To determine whether we send proxy IPs we depend on the allowed_ips, since that's where we track what resources we have sent to a given gateway.
However, the way we were matching if a given resource destination was sent was using longest_match and with overlapping DNS this no longer works, since this will match for internet resources even if the proxy IP wasn't sent.
So we check that it's a DNS resource and if it's we exactly match on the allowed ip table.
Alternatively, we could keep track of  sent_ips for a gateway, though this is a bit of a redundant state that we need to keep in sync but has the benefit of being more explicit, so I'm open to do that in a follow up PR. But I'd like to merge this to get ready for internet resources.

LGTM
Can you add an item to the tracking issue for extensions to tunnel_test to try and cover this?

Added to #2667 as "State machine proptest for internet resource"
Thinking that it might be easier to test when we handle that as a separate resource rather than 2 separated CIDR resource as we do now.


Feat: Adding Twitter Authentication

Describe the feature
@SUGAM-ARORA I want to add Twitter Authentication . Kindly assign me this issue.
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@Ojas-Arora Issue assigned to you


Some code samples for DOM

Hello:
I need to monitor a remote web site"www.randomNum.com", (a fake domain name), which has a lot of JavaScript scripts, one of them is like this one (I just show the important code to make things simple)
<!doctype html>

Simple Random JavaScript

The web site will from time to time run the JavaScript to show a random number on its web site, the time, the script run is totally random.  I want to write a C# project using AngleSharp to monitor the web site, but try to use querySelectorAll to get the random number generated by the JavaScript.
I have some C# code like this: (I am using Visual Studio 2017 Version 15.9.2 with C# 7.3 on Window 10)
static async System.Threading.Tasks.Task Main(string[] args)
{
var random_numbers = new List();
IConfiguration config = Configuration.Default.WithDefaultLoader().WithCookies();
IBrowsingContext context = BrowsingContext.New(config);
await context.OpenAsync("www.randomNum.com");
IElement[] numbers = context.Active.QuerySelectorAll("CurrentNumber").ToArray();
for(int i = 0; i < numbers.length ; i++)
{
random_numbers.add(decimal.parse(numbers[i].toString));
}
}
}
The above code works for the first time, when the web page fully loaded from "www.randomNum.com", but how I can rewrite my code, so each time, when the web page dynamically generates a random number, I can use C# code to get its current generated number.  The time when the JavaScript will generate the random is totally out of my control, it is controlled by other JavaScript scripts on the same web site, but I don’t care about the other JavaScript scripts, I only need to get the current generated random number.
So I want to know how I can write some code to monitor some JavaScript event like DomContentLoaded or some other Web event, like download_completed/document_completed or even if I can use something like Web Browser reload/refresh, but I can’t find AngleSharp has reload/refresh methods available to call.
Please advice, and as my knowledge for AngleSharp and JavaScript are both limited.
It is better to share me some C# code or at least give me some web link where I can see the C# code for this.
Thanks,

See #725.


iCub SEA legs - Hard and Soft joint limits

Which are the hardware and software joint limits for the iCub SEA legs?

The issue collects the HARD and the SOFT joint limits for the iCub SEA legs (Series Elastic Actuator legs).
The SEA legs are generally assembled on all version of iCub 2.5 and on the first version of the Koroibot robot.
The joint limits are defined as follows:

The HARD joint limits are enforced at the joint level through a mechanical hard stop (e.g. a pin).
The joint limits have been extracted from the CAD model of the left leg.
The assembly name is: RC_IIT_018_A_012.
The SOFT joint limits are enforced at the firmware level.
The values have been copied from the iCubGenova04 configuration file.

The following table recaps the joint limits for the complete leg:

HARD
HARD
SOFT
SOFT

JOINT NAME
UPPER LIMIT [deg]
LOWER LIMIT [deg]
UPPER LIMIT [deg]
LOWER LIMIT [deg]

hip_pitch
134
-45
85
-30

hip_roll
120
-20
85
-15

hip_yaw
80
-80
70
-70

knee
4
-124
0
-100

ankle_pitch
35
-35
-30
30

ankle_roll
25
-25
20
-20

HARD joint limits
l_hip_pitch

l_hip_roll

l_hip_yaw

l_knee

l_ankle_pitch

l_ankle_roll

cc: @traversaro @DanielePucci @francesco-romano @gabrielenava @S-Dafarra @pattacini
related issues:

https://github.com/loc2/element_icub-at-ihmc/issues/2
https://github.com/robotology-playground/icub-model-generator/issues/48
https://github.com/robotology-playground/icub-model-generator/issues/5

Hi @fiorisi, thanks a lot for the effort. Crystal.
Did you by chance check that these limits are met also on a "real" robot we have in the lab?

The joint limits have been checked on the real robot. The problem is that in this case it is necessary to take into account cover self-collisions.
The joint limits have been measured with the Yarp robot motor GUI from the left leg of the iCubGenova04 robot.
The following table recaps the joint limits for the complete leg:

REAL ROBOT
REAL ROBOT

JOINT NAME
UPPER LIMIT [deg]
LOWER LIMIT [deg]

hip_pitch
100
-20 *

hip_roll
85
-10 *

hip_yaw
55 *
-55 *

knee
4
-110

ankle_pitch
34
-34 **

ankle_roll
25
-25

(*) NOTE: the joint limits of the hip have complex interdependencies. If the SOFT limits are used, when the joint hip_yaw is rotated close to its limit (either 70 or -70), the covers can collide with the waist when moving the other hip joints (namely, hip_roll and hip_pitch). For this reason the REAL ROBOT limits have a smaller range of motion.
(**) NOTE: in the CAD model, the joint has a cover collision before reaching the limit value. Nevertheless, probably due to deformations during the production of the covers, there is no collision on the iCubGenova04.
This problem will be fixed ASAP in the CAD model.
l_hip_pitch

l_hip_roll

l_hip_yaw

l_knee

l_ankle_pitch

l_ankle_roll

Nice. I think we can also update the corresponding urdf models then
@traversaro @francesco-romano @pattacini

The file to update is https://github.com/robotology-playground/icub-model-generator/blob/master/simmechanics/data/icub2_5/ICUB_2-5_BB_joint_parameters.csv .
We should also update the iCubHeidelberg01 model, but that one is still not integrated in the repo for some issues:

https://github.com/robotology-playground/icub-model-generator/pull/15
https://github.com/robotology-playground/icub-model-generator/issues/35
https://github.com/robotology-playground/icub-model-generator/issues/16

That applies also to our iCubNancy01, right? In that case we should update also our URDF, right? Can we assume the same values for the covers (collisions)?
@dogoepp @InriaBrice @olivierrochel-inria

@fiorisi could you take on @serena-ivaldi's question?

Please open a new issue for your robot

After a double check on the robot with @fiorisi we noticed that the limits were bigger than what written initially. The table in the second comment has been updated together with the corresponding CAD images. This time the range has been measured by constraining the pin to be coincident with the hard limit surface (initially the range of motion was measured considering only the hollow, but the pin as a smaller radius, causing the inconsistency noticed above).
Notice that it is also possible to reach all the leg joints hard limits, except from the knee lower limit due to the cabling. All the other limits are more or less trivially reachable even with the covers mounted. The tricky ones to be reached are the hip roll limits. The upper limit can be reached by bending the leg in this pretty awkward position, where also the pitch and the yaw are close to their limits:

The hip roll lower limit instead can be approached when the robot is not on the pole, even if it cannot be mechanically reached because the upper leg is hitting the hip_pitch pulley:


feat(dbt-fal): make dbt-fal work with sqlserver

Description
Adds support for sqlserver adapter
Closes #778

@chamini2, should we add integration tests for sqlserver? Not sure about the overhead.

@chamini2, should we add integration tests for sqlserver? Not sure about the overhead.

I would say we should @mederka. We can later make some tests run only in certain cases, but having the integration tests seems important if we have sqlserver code


New control panel UI

New control panel; new placement for topic name; "Modify topic" instead of create new snapshot; "reset" button instead of back icon (@rahulbot — maybe we need to talk this one through, because this isn't something we've discussed yet)

Control panel open: pick a sub-topic, search within topic, snapshot archive

Filters applied (chips)

"Filter" icon: filter.svg.zip
"Modify" icon (Pencil): modify.svg.zip
"Reset" Icon: reset.svg.zip


search needs improvement

I think the current search implementation is missing some exact match vs term match logic. For example:
http://shazwazza.com/search?term=Examine+custom+index+SimpleDataIndexer
This shows that the best matching post is: http://shazwazza.com/post/using-aspnet5-optionsmodel/
which is definitely not correct

The cause was actually do to a re-sorting of the results which was incorrect


Pretrained_model issue

Hi，I'm interested in your project but I met an issue. I can't get the full pretrained model parameters through the link you given in Readme. I have tried many times with IDM connecting failed. Moreover, could you provide them in Google.drive or Baidu netdisk?

Hi @flying318
Did you try to download the pre-trained model weights via wget command?
wget https://www.dropbox.com/s/undtrlxiz7bkag5/pretrained_changeformer.pt


Add EhPanda by @tatsuz0u

[x] Project URL: https://github.com/tatsuz0u/EhPanda
[x] Update contents.json instead of README
[x] One project per pull request
[x] Screenshot included
[x] Avoid iOS or open-source in description as it is assumed
[x] Use this commit title format if applicable: Add app-name by @github-username
[x] Use approved format for your entry

@tatsuz0u thx!


eventlog: simplify "notifying observer" to "notifying"

#75  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @jespert and the rest of your teammates on  Graphite

Merge activity

May 19, 3:04 AM EDT: @jespert merged this pull request with Graphite.


[Fix 1169 ]Pr create web assets dir in template

All Submissions:

[x] Have you followed the guidelines stated in CONTRIBUTING.md file?
[x] Have you checked to ensure there aren't any other open Pull Requests for the desired changed?

Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

New Feature Submission:

[x] Does your submission pass the tests?
[x] Have you linted your code locally prior to submission?

Changes To Core Features:
After these steps, you're ready to open a pull request.
a. Give a descriptive title to your PR.

b. Describe your changes.

c. Put `closes #XXXX` in your comment to auto-close the issue that your PR fixes (if such).

This PR is the Method 1 to solve the following issue.

https://github.com/pynecone-io/pynecone/issues/1169
Make a folder public including .gitignore file in template

Closed because we merged #1171


As a new user, I want to be able to register for an account so that I can access the site's features.

Feature: As a new user, I want to be able to register for an account so that I can access the site's features.
Scenario: Successful account creation
Given: I am a new user
When: I fill in a unique username in the username field
And: do the same for the email field
And: the password field
And: confirm the password
And: click the register button
Then: the account will be registered

Feature: As a new user, I want to be able to register for an account so that I can access the site's features.
Scenario: Successful account creation
Given: I am a new user
When: I fill in a unique username in the username field
And: do the same for the email field
And: the password field
And: confirm the password
And: click the register button
Then: the account will be registered


Multiple Highlighter Support

Description
Adds support for multiple highlight providers.

[!NOTE]
For reviewers: You may notice that this uses an underscored module _RopeModule. This module is safe, as in it has tests and is used in production (it backs AttributedString and BigString Foundation types). It's underscored because the API may change in the future, and the swift-collections devs consider it to be the incorrect collection type to use for most applications. However, this application meets every requirement for using a Rope.

Related Issues

#40

Checklist

[x] I read and understood the contributing guide as well as the code of conduct
[x] The issues this PR addresses are related to each other
[x] My changes generate no new warnings
[x] My code builds and runs on my machine
[x] My changes are all related to the related issue above
[x] I documented my code

Screenshots
N/A

Quick fix, fixed a bug where when the visible set was updated it'd invalidate the whole visible range rather than just the new indices. Also fixes a bug where the entire document could have attributes set (and therefore layout invalidated for the entire document). Added a test to make sure this doesn't happen in the future.

Thanks y'all for the review work, but I'm going to have to draft this for a minute. I found a few cases of incorrect/different highlights that I think has to do with tree-sitter returning overlapping captures.
I might take this opportunity to add some more rigorous syntax highlighting testing, eg dumping highlights to a file to test against to help future proof this system.

Alright I've got a pull request open for the issue I mentioned, it's only a problem for this highlight system so I've made it based on this branch. Both are ready for review now


Feature to change the question type and retain the information already entered

Is there a way to change the type of questions midway after entering the title and still retain the texts? The current available method is to create a new question and then copy the content of the original question over to the newly generated one. This seems unintuitive.

you can change the question type if it's of the same type, but not otherwise. e.g select list, radio, and checkbox are all selection items

Is there a reason why it's not possible to retain at least the question title on text <-> selection type change? (it's really Google Form-ish)

i guess that's not expected but we can change it, sure, going from select to text and back to select would mean that only the question is retained the options would be gone!

i put this into the backlog, we will do it later

will reopen if necessary


Segment: find closest t value for a given point

Added optimized method for Line, should add other optimized methods.


Fix paging links format in trade aggregation.

Closes #160

@nullstyle The links are followed through and tested in the old tests. I added a small test to make sure the next link begins with 'http' because the RequestHelper is happy with both paths and fully qualified urls.

@nikhilsaraf We probably just need to rewrite the horizon tests to use the stellar/go/support/http/httptest package.  Given that it leverages the net/http/httptest package, moving should eliminate discrepancies between test and real requests.


Can't install on windows

Hi
I'm new to Ruby, I'm running Windows and installed ruby via choc install ruby. This is currently my gemfile:
source "https://rubygems.org"

gem 'jekyll'
gem 'hawkins'

When I run bundle install I get the following error:
Gem::InstallError: The 'http_parser.rb' native gem requires installed build
tools.

Please update your PATH to include build tools or download the DevKit
from 'http://rubyinstaller.org/downloads' and follow the instructions
at 'http://github.com/oneclick/rubyinstaller/wiki/Development-Kit'

An error occurred while installing http_parser.rb (0.6.0), and Bundler cannot
continue.
Make sure that `gem install http_parser.rb -v '0.6.0'` succeeds before bundling.

I figured out the issue, chocolatey wasn't installing ruby and the devkit correctly on windows. I followed the instructions here instead: http://jekyll-windows.juthilo.com/1-ruby-and-devkit/
However now I am getting
Unable to load the EventMachine C extension; To use the pure-ruby reactor, require 'em/pure_ruby'
C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/eventmachine-1.2.5-x64-mingw32/lib/rubyeventmachine.rb:2:in `require': cannot load such file -- 2.4/rubyeventmachine (LoadError)
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/eventmachine-1.2.5-x64-mingw32/lib/rubyeventmachine.rb:2:in `<top (required)>'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/eventmachine-1.2.5-x64-mingw32/lib/eventmachine.rb:8:in `require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/eventmachine-1.2.5-x64-mingw32/lib/eventmachine.rb:8:in `<top (required)>'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/em-websocket-0.5.1/lib/em-websocket.rb:3:in `require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/em-websocket-0.5.1/lib/em-websocket.rb:3:in `<top (required)>'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/hawkins-2.0.5/lib/hawkins/websockets.rb:2:in `require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/hawkins-2.0.5/lib/hawkins/websockets.rb:2:in `<top (required)>'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/hawkins-2.0.5/lib/hawkins.rb:8:in `require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/hawkins-2.0.5/lib/hawkins.rb:8:in `<module:Hawkins>'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/hawkins-2.0.5/lib/hawkins.rb:3:in `<top (required)>'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/bundler-1.15.3/lib/bundler/runtime.rb:82:in `require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/bundler-1.15.3/lib/bundler/runtime.rb:82:in `block (2 levels) in require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/bundler-1.15.3/lib/bundler/runtime.rb:77:in `each'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/bundler-1.15.3/lib/bundler/runtime.rb:77:in `block in require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/bundler-1.15.3/lib/bundler/runtime.rb:66:in `each'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/bundler-1.15.3/lib/bundler/runtime.rb:66:in `require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/bundler-1.15.3/lib/bundler.rb:108:in `require'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.5.1/lib/jekyll/plugin_manager.rb:49:in `require_from_bundler'
        from C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.5.1/exe/jekyll:9:in `<top (required)>'
        from C:/Ruby24-x64/bin/jekyll:22:in `load'
        from C:/Ruby24-x64/bin/jekyll:22:in `<main>'

That stack trace indicates that the problem is in em-websockets and/or eventmachine rather than in Hawkins.
See the advice at https://stackoverflow.com/questions/14824235/rails-cannot-run-app-unable-to-load-the-eventmachine-c-extension and see if that helps.


To begin, I find myself agreeing with various people on the nature of what JSX actually is and how it benefits developers. First and foremost, JSX was designed as a form of "dynamic HTML" that could be inlined into existing Javascript code. It's indispensable for JS-based web platforms like React in that it enables web developers to cleanly and efficiently interact with the DOM without having to wrestle with the god-awful native way (or the only-slightly-better jQuery way). Also, by its very nature, JSX encourages UI development that can be easily decoupled from the underlying data, promoting a well-organized project structure. In that environment, JSX is a tool to enable greater productivity, and I feel that it would be virtually impossible to argue with that.
How that paragraph relates to React-Native is that, even though it is a mobile-development platform, it is directly descended from React. As such, nearly all of the syntax and paradigms were still originally created with web-development in mind. That is by design - RN's whole shtick is that you can "create cross-platform mobile apps using React", so it's supposed to feel like web development when using it.  RN apps are also predominantly written in Javascript, so the inclusion of JSX is a natural one. JSX helps RN development for nearly all the same reasons that it helps in web development. (I really think that this is one big reason that, in RN at least, the JSX approach is used so much more frequently than the native approach. RN itself just feels like a web platform, so the more web-natural approach is inevitably going to become predominant.)
Flutter, on the other hand, has no such design philosophy. It is intended to be a purely native cross-platform solution, and though it states that it was inspired by React-Native, it writes a lot more like a native desktop or mobile app than a web app. It also runs using Dart and not Javascript, which from the standpoint of integrating something like JSX is a major consideration. For one, while the JS DOM functions can horribly verbose (both because of the function's design and the JS language itself), Dart as a language is much more facilitating of clean UI-declarative code while Flutter for the most part does a good job of keeping UI constructors concise. For another (as @sandangel pointed out) Dart is a statically-typed language, so the nature of JSX being designed for a dynamically-typed language like JS is going to run into snags in cases where, for example, a UI constructor requires a Widget of a specific type, the only solution to which just adds to the verbosity. Personally, it feels like a solution that, over time, will inevitably result in a DSL that has gotten bloated and difficult to maintain as it has to account for a growing number of use cases inherent in a system that it wasn't intended to be used for.
As such, I really don't see how JSX/DSX would benefit Flutter development productivity beyond just being a matter of personal preference. Both syntaxes overall are roughly equivalent in verbosity, and where one loses verbosity in specific instances it makes up for it in clarity (the closing XML tags, for example). It largely boils down to if someone is coming to Flutter from a web-oriented background (React/RN, Angular, etc.) or from a native background (Java/Kotlin/Swift, WPF/UWP, etc.) that will determine which approach they would prefer. Even on this thread alone, there are a lot of user stories that say they were extremely skeptical of JSX at first but after using it for a few months changed their opinion to "can't do without". (Though the cynical part of me wants to point out that the same thing could very well happen to them for the native Dart approach if they gave it a chance.)
All that being said, I can't really see myself agreeing that DSX should become officially supported by the Flutter team as an alternative to native UI constructors. While it's perfectly fine as a third-party solution (and all the props to @cbazza for actually implementing it), it doesn't really fit with the core nature of Flutter as a non-web-technology-based platform. As such, I would side with the mindset that there are plenty of other more important things the Flutter team could and should be spending their time on.
Now with THAT being said, while I don't really agree with DSX being officially supported, I do think that there should be an official UI format of some kind. As @birkir pointed out, nearly every major native UI platform, be it desktop or mobile, has a UI format in addition to the direct code-based approach (and most of them are pre-processed into the code-based approached anyway). Having separate UI files from logic files has always been the recommended way to embrace the MVVM pattern (which, incidentally, is one thing that has always rubbed me the wrong way about JSX). What I would argue, therefore, is that Flutter have something similar - instead of an inline UI DSL format, it should have a separate UI format that is intended to go into its own file away from the Dart code.
As part of this line of thinking, I've actually done some work this past weekend along that end. If I could be allowed to shill for a moment, I developed a project that I've coined "FLUI" that is my attempt to show what such a format might look like. Rather than going with an existing DSL (or a modified version), I developed an entirely new one that takes inspiration from YAML and I've tried my best to keep close to the "feel" of the Flutter-constructor-approach layout. Granted, it's a very early implementation, so I don't really expect it to not have a massive slew of issues, but I've included the source for the processor script (written in C#/.NET Standard) so that people can play with it if they want to. :)

As both a React/RN and a Flutter user, I heavily disagree with the idea of  "DSX".
DSX would bring nothing. JSX is used in react because the JS syntax is horrible. But in the case of Flutter, widgets creations is super easy.
The classical :
Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  );
}

it is already out of the box readable, easy to write, type/generic compatible, and without any unneeded duplication.
The only complain you could possibly have with the current syntax is "It is hard to know where is the closing parenthesis of a widget"
But then again, dart plugin of the officially supported IDEs solves this problem. So that when we open the code from before in say vscode, we'll see
Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  ); // Center
}

As for the "It's hard to differenciate casual code from UI code", react rules apply to flutter too :
Widgets should be either dumb or smart. Smart widget don't have UI logic.
If you follow this pattern, you should never fall into a situation where you fail to differentiate UI from the rest.
This is even more true when following something like BLoC pattern; which heavily enforce separation of business and UI.

JSX is used in react because the JS syntax is horrible

Very opinionated statement and simply not true.

render() {
  return React.createElement(Container, { padding: EdgeInsets.all(20.0) },
    React.createElement(Text, { style: { color: Colors.black } },
      'foo'
    )
  );
}

Widget build(BuildContext context) {
  return Container(
    padding: EdgeInsets.all(20.0),
    child: Text(
      'foo',
      style: TextStyle(color: Colors.black)
    ),
  );
}

render() {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={{ color: Colors.black }}>foo</Text>
    </Container>
  );
}

Widget build(BuildContext context) {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={TextStyle(color: Colors.black)}>{'foo'}</Text>
    </Container>
  );
}

Very opinionated statement and simply not true.

There's a lot of unneeded characters in the default react syntax.
Let's compare words repetition and characters count for each syntax (excluding function definition, indentation and 'return')
React without JSX:

133 characters, including 3 parenthesis, 3 brackets, 3 :, 4 , and 11 spaces
React.createElement written twice

JSX:

104 characters, with  2 parenthesis, 3 brackets, 1 :, 4 <> and 5 spaces
Container and Text written twice

Dart:

99 characters, with 2 parenthesis, 4 :, 3 , and 4 spaces
No repetition

In term of characters, the obvious winner here is dart syntax.

Now we also have to take other dart specifics into account.
Dart types single child vs multi-child, const constructors and allows generics. JSX supports none of these.
In fact, child doesn't even makes sense as a property name in many situation
A few examples that would badly convert to JSX :
Not always children:
Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

const constructor on widget themselves
const Padding(
  padding: const EdgeInsets.all(4.0),
)

generics
NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

@rrousselGit
As mentioned several times before DSX is simply a different
syntax and it is a superset of Dart, so everything you can do with
Dart you can do it inside DSX. You can also mix and match both
syntaxes as you see fit. Obviously you did even bother to check
out what are some of the DSX features that were done to support
Dart:
https://spark-heroku-dsx.herokuapp.com/index.html
-1---------------------------------------
In Dart:
Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

In DSX:
<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

OR

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

-2---------------------------------------
In Dart:
const Padding(
  padding: const EdgeInsets.all(4.0),
)

In DSX:
const Padding(
  padding: const EdgeInsets.all(4.0),
)

-3---------------------------------------
In Dart:
NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

In DSX:
<NotificationListener<ScrollNotification>
  onNotification={(foo) {

  }}
  child={child}
/>

-4---------------------------------------
In Dart:
Text("foo")

In DSX:
<Text ["foo"]/>

-5---------------------------------------
In Dart:
Positioned.fill(
  child: Container(),
);

In DSX:
<Positioned.fill>
  <Container/>
</Positioned.fill>

-6---------------------------------------
In Dart:
Builder(
  builder: (context) => Container(),
)

In DSX:
<Builder
  builder={(context) => <Container/>}
/>

But then the argument of having an easier conversion from react to flutter is invalid. As JSX is radically different from your prototype :
<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

And none of your examples here or from your link actually simplify the code or improves readability
As much as I can relate to your feeling of missing JSX (got the same when starting flutter), after some experience, the native syntax feels much pretty good actually

As a side note, there's a much better solution to your separation of concern. That is a template file
You could have an xml/yaml file your widget. And then use the awesome code generation tooling dart provides.
I'd rather prefer a :
import 'package:flutter/material.dart';

part 'main.g.dart';

class MyState extends StatefulWidget {
  @override
  _MyStateState createState() => _MyStateState();
}

class _MyStateState extends State<MyState> with Template {
  @override
  Widget build(BuildContext context) {
    return buildTemplate(theme: Theme.of(context));
  }
}

combined with a
@theme ThemeData

<Container<EMAIL_ADDRESS>/>

which then using a custom code-gen generates the following dart file :
part of 'main.dart';

class Template {
  Widget buildTemplate({ ThemeData theme }) {
    return Container(
      color: theme.cardColor,
    );
  }
}

The end result is even better than a "DSX" for separation of UI/logic. It's even better for potential UI generators.  And it's much easier to implement using built.

As JSX is radically different from your prototype :

Really !!! The only thing radical in these discussions has been the reaction of the naysayers.
As it's stated in the title of this ticket, DSX is JSX-like, it is not JSX-identical or else it would had been called JSX; and the additions to it are minor and provides options to developers.
You could write it like:
<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

or

<MyAppBar>
    <title:Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>
</MyAppBar>

or

<MyAppBar
    title={<Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    <Text>}
/>

or

<MyAppBar
    title={<Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>}
/>

Hummmm, you seem to be confusing 'separation of concern' with 'separation of technology'. These things are very different; you separating dart code and markup code in different files, is simply 'separation of technology' and provides none of the benefits of 'separation of concerns'. A concern here would a component/widget that encapsulates reusable code cleanly, it doesn't matter that inside that component/widget it is using different technologies.
Also separating technologies as you recommend is highly inferior to JSX/DSX which uses the host language for all of its imperative constructs (for loops, function calls, if statements, etc).

After much of code and examples posted here (especially), I come to conclusion, that JSX adds much more value to JS in contrast to DSX and Dart. But one feature is very important from my point of view: Closing tags. Like:
<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

reduces a LOT of cognitive complexy in deep structures like here in contrast to:
SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

But well, if you use it like this:
<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

there is a small profit.

As it's stated in the title of this ticket, DSX is JSX-like, it is not JSX-identical

You missed my "But then the argument of having an easier conversion from react to flutter is invalid."
Half of the arguments for DSX is "JSX is popular in react, we need this here too". But you're proposing something different (and more complex) from JSX.
The other half is about separating UI from code; which a template file can do too.

Also separating technologies as you recommend is highly inferior to JSX/DSX which uses the host language for all of its imperative constructs (for loops, function calls, if statements, etc).

Not true. You could do if and stuff inside your template file. Look at cshtml or angular templates.
The thing is a template file, as long as you already have a parser for it, could be implemented for flutter in less than a week fully working.
Be it yaml, xml, cshtml, or html with directives.
While a DSX would require a lot of work.

@Bessonov They recently added virtual comments on supported IDEs to mock closing tag.
So in your vscode you'll see the following :
SingleChildScrollView(
  child: Container(
    height: 100.0,
  ), // Container
) // SingleChildScrollView

@rrousselGit

They recently added virtual comments on supported IDEs to mock closing tag.

Yeah, I've seen that in cited comment. But it's not the same. This introduce an align shift and disturb reading flow. And this doesn't help me in other IDEs and text processors.

The thing is a template file

IMHO templates suffers from NIH syndrom. I don't say that approach to mix PHP and HTML is the right way to do that. But react shows with JSX how it can be done better.

You missed my "But then the argument of having an easier conversion from react to flutter is invalid."

No, I didn't miss the comment at all, it just makes no sense you telling me that people coming from JSX will find DSX too complex.

Half of the arguments for DSX...

There are many reasons to choose DSX but with alternatives people will pick what they prefer for whatever reason they have.

Not true. You could do if and stuff inside your template file. Look at cshtml or angular templates.

The thing is a template file, as long as you already have a parser for it, could be implemented for flutter in less than a week fully working.
Be it yaml, xml, cshtml, or html with directives.

While a DSX would require a lot of work.

Totally opposite, DSX only implements 2 xml transforms and gains everything else for free from the hosting language. Imagine the effort trying to re-implement the power of Dart inside your new templating language. No thanks, I'll take Dart.

No, I didn't miss the comment at all, it just makes no sense you telling me that people coming from JSX will find DSX too complex.

The same thing applies to the current dart implementation.

Anyway, I don't think we can convince each other here. So I'll just list a few more reasons as to why I dislike JSX in flutter and then "wait and see".
1. Widget creation is different from React
In react, it's the library that handles components creation. JSX is fine because it says "Don't bother about how things work. We do things for you".
In flutter that is not the case. We manually instantiate a new widget every on build call. This is really important to understand, and JSX would make it less clear.
And, in the continuation of that logic :
2. Peoples may think <Foo /> does something special that new Foo() don't
<Foo />  in a method feels special. It seems like it does something extraneous built-in in the framework. Which is true in react, where  components are wrapped into a React.Element.
This translates in react into <Foo /> != new Foo() and don't have direct access to Foo.
This doesn't apply in flutter and may cause confusion.
Also :
<Foo>
  <Bar />
</Foo>

In react, if Foo never uses its child then Bar is never instantiated. And Foo is instantiated after the render method returns.
While in flutter this is the opposite. Both Bar and Foo are created immediately
This would potentially lead in React developers making un-optimized flutter code.
3. In general Dart/flutter is not JS/react
If we add JSX in dart, I can already see the issues about type union or be able to do
return foo && <Component /> or the upcoming async rendering in react.
Justified with a "we already have JSX so we can have that too !"
I'd prefer a proprietary syntax or no syntax at all, for the sake of not having to implement the latest JSX/react feature in dart
4. JSX makes some dart specifics unclear
A small example, Scaffold requires for appbar a PrefferedSizeWidget.
If we created Scaffold using JSX, peoples would expect that you can replace any given JSX with another. Which is not true
I mean, it makes it very unclear why we can do
<Scaffold
  appbar={<AppBar />}
/>

but not
<Scaffold
  appbar={<Container />}
/>

@rrousselGit

Anyway, I don't think we can convince each other here. So I'll just list a few more reasons as to why I dislike JSX in flutter and then "wait and see".

I disagree with a lot of what you said but I appreciate your effort since you are taking the time to think deeply into the issue.

Widget creation is different from React

To me it doesn't matter because this is just an implementation detail, conceptually once you see some XML, in React it is a Component, in Flutter it is a Widget.

Peoples may think  does something special that new Foo() don't

I think people will learn pretty quickly that Dart/DSX is not Javascript/JSX.

In general Dart/flutter is not JS/react

Yes, we finally agree on something but even though they are different the common thread is that they are declarative UI frameworks and I think declarative tree structures are handled nicely with JSX/DSX. It keeps you on the declarative programming way of thinking.

If we add JSX in dart, I can already see the issues about type union or be able to do return foo && <Component /> or the upcoming async rendering in react.
Justified with a "we already have JSX so we can have that too !"

We are not adding JSX in Dart, we are adding DSX, it is different but has similarities to JSX and familiarity is a huge thing.

I'd prefer a proprietary syntax or no syntax at all, for the sake of not having to implement the latest JSX/react feature in dart.

So with that reasoning why are you using Dart? it looks pretty similar to Java and yet it is different than Java; the heck with it, let's scrap all of these Java keywords and concepts and come up with something vaguely similar to Erland that you can only program with one hand while doing a pretzel yoga move on top of Mount Everest ;)

JSX makes some dart specifics unclear

Not really, if you connect incomparable Widgets the Dart compiler will spit error messages just like if you did it in plain Dart. I can not emphasize enough that DSX is simply thin syntactic sugar, there is no magic, just a difference syntax to the same thing.

A fierce debate raged over the DSX, Could flutter provides an intermediate option that is neither DSX nor now way with Dart, and express the UI in a more explicit way such as angular or any others？

@cbazza I spent hours reading your posts and I really appreciate your effort on this issue. But I think it is (kind of) easy to end the argument. Remember that flux was the official state management solution for react but now everyone is using redux? And how many navigation libs are there for react-native? Just make a DSX repo and let react devs jump in.

@andrewackerman
part/part of is an existing dart feature. It somehow joins two files into one. Usually used for code generation.
There are a few real cases scenarios that use such technique.  Like json_serializable which generates a toJSON method and a fromJSON factory for classes based on their properties.
part/part of don't really do anything on its own. The interesting part is when you combine it to something like source_gen.

@sunnylqm
I don't think putting code on a repo would solve my problem because the current issue is about properly integrating DSX with Flutter tools as to provide a great developer experience with debugger, auto-complete, etc. working on .dsx file.
Telling users that they can use DSX but can't use debugger or enjoy auto-complete is a non starter for me. If anybody wants to help, what I need is to figure out a way to add full preprocessing support (with source map) to Dart Tools and VS Code Dart plug in. Once the tools support that DSX or any other transpiling language (any language that is a superset of Dart but compiles everything down to Dart) would just work.
@andrewackerman
I don't need to justify anything, I am very confident that DSX will be a hit and there are almost 100 people interested in it on this ticket alone.

Failing that, without pre-processing and tooling support, the only way DSX would work is with external manual conversion tools, which is just another (potentially lengthy) step that developers will have to go through.

The DSX transpiler is blindingly fast and can transform .dsx files into .dart files faster than you can blink, so speed is not a problem; just trying to get feature parity as to make it a no-brainer for people to use DSX.

If that's the case, why is React the only framework with market presence that is using it? Both native and cross-platform mobile app frameworks have stuck with their storyboards, their XML files, their XAML files, and other such UI definition DSTs.

Just make a timeline and you will see the UI development evolution. Android and iOS development via their current ways started over 10 years ago so it uses 10 years old techniques (totally imperative techniques). The Reactive UI development (declarative) techniques started to appear for the web around 8 years ago. React appeared 5 years ago and it was the first Reactive framework to combine technologies seamelessly with JSX. Vue is now the latest Reactive framework that supports the older 'separation of technologies' techniques but it also supports JSX. On mobile Flutter is the latest and it uses Reactive framework techniques as React and it could take advantage of DSX just as Vue takes advantage of JSX. Vue is killing Angular because it is providing choice to developers and not being overly opinionated.
The problem with separate template files is that the imperative programming constructs there (if, for loop, etc) are so weak compared to what's available on the programming language used for the business logic. Combining the 2 in the way JSX does, to me, is clearly the future.

React developers talk like JSX is the way of the future,

It is !!!

but I've yet to see it pop up anywhere other than in React in a framework that has gotten any real traction.

Vue uses JSX

Vue uses JSX

Vue specify has a broad variety of usages. JSX is just "there". But it's not the dominant syntax
You could plug JSX to Angular if you wanted to.  Although nobody does

React developers talk like JSX is the way of the future,
It is !!!

Actually, it's web-components the future. And they are used directly in html similar to what you'd find in Angular or the most common form of Vue

@andrewackerman

just the fact that the developer has to go through another checklist of manual actions before they can build is enough of a turn off for many people.

Who said anything about manual actions? Didn't I make myself clear that I am trying to get complete seamless IDE integration (best possible user experience for developers).

You also have yet to actually release the source code of the project, so no one's been able to go through your process, double-check your findings, and suggest improvements.

How does that have anything to do with people using DSX? I've used JSX for over 2 years and couldn't care less for its source code. Do you need to look at the source code of the Dart compiler to be able to program in Dart?

what I will say is that in not a single one of them have I ever seen JSX actually utilized - people seem to massively prefer the .vue approach (template-script-styling) over the render+JSX approach.

JSX is a new addition so it will take time to spread but the important point to get is that Vue accepts other approaches without forcing developers to use 'the correct way and only way' that things should be done in Vue.

Vue is still a Javascript framework. Flutter is most assuredly not.

Riiiiight, so instead of JSX you use DSX with Flutter.
@rrousselGit

A big candidate for the future is web-components.

Web components are zoobies, dead but still walking; they are as widespread as kangaroos in Canada. I could go on for days but to avoid digressing...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

@cbazza

Who said anything about manual actions? Didn't I make myself clear that I am trying to get complete seamless IDE integration (best possible user experience for developers).

You also said that you needed preprocessing support from the Flutter/Dart team in order to do so. Am I incorrect in that?

How does that have anything to do with people using DSX? I've used JSX for over 2 years and couldn't care less for its source code.

JSX was developed by Facebook for React, put through a rigorous proposal/design/implementation/iteration process, and then released into the world years before you got your hands on it. It's been rigorously tested and proven time and time again in real world environments. It's a mature technology. There's no reason to demand to see a spec sheet for something like that.
DSX, on the other hand, is being developed today by you and a handful of people. You've waxed eloquently about what it can and will be able to do, but all we've actually seen is a small handful of purpose-built code snippets and your word that they were generated by the transpiler. People who have even want to try it out and suggest possible changes or improvements aren't able to do so, so they have no reason to support your efforts beyond "Yay JSX!".
I'm not accusing you of lying or anything, I'm just saying that JSX has earned a level of faith that DSX has not, so how are you going to turn some heads if you don't let people tinker with it?

JSX is a new addition so it will take time to spread but the important point to get is that Vue accepts other approaches without forcing developers to use 'the correct way and only way' that things should be done in Vue.

JSX has been in Vue for almost 2 years now. And unlike Vue itself, JSX is a pre-existing technology that needs no introduction, especially for people familiar to React. If JSX was going to take the Vue.js world by storm, I can't help but feel it would've done so by now. (Particularly if it's any indication that as many people are clamoring for JSX in Flutter as you claim.)

Riiiiight, so instead of JSX you use DSX with Flutter.

JSX and DSX are the same syntactic concept. The problem is that, where JSX was built on a weakly-typed dynamic language like JavaScript, DSX is being built on a strongly-typed static language like Dart. That means there are lots of problems DSX will have to account for that JSX didn't have to if it's going to be anything other than a niche "JSX for Flutter" implementation, and it's going to take some ingenious modifications to make DSX really work without making it too bloated to justify claiming that it's more visually concise.
And to address the "DSX is just Dart, if DSX can't do something, just use Dart" rebuttal, then my counter-rebuttal would be if I have to keep falling back to Dart whenever I run into a scenario that DSX doesn't handle, then why shouldn't I just use Dart all the time?
And to address the rebuttal for that reading "you can if you want to, DSX is just an option", then you are really selling yourself short. Even if it really is just going to be "an option", it still needs to bring something to the table that is going to convince people to use it. You yourself said that DSX is not JSX, so people who want just JSX aren't going to get what they want. That means there needs to be some tangible reasons beyond the "JSX-like appeal" for people to want to use it.
If you're just building a tool that you yourself want to use, then all this is moot and you can go nuts. But if you are actually building something you intend for other people to use, then you need to put it in a solid form why you think they should.

Web components are zoobies, dead but still walking; they are as widespread as kangaroos in Canada. I could go on for days but to avoid digressing...

Somewhat off-topic, but I would like to point out that web components really are a promising look at the future, even if support for them is getting added slower than tar. Think about it this way: React does what it does because it essentially implements the idea of web components in Javascript-only. Imagine how much better it would be if those features were supported by the browser and benefitted from non-sandboxed performance and not having to operate through DOM manipulation? (Granted it might be another 20 years before we find out, but still...)

@andrewackerman
Sorry dude I don't have the time to argue endlessly and repeat what I said before over and over; we won't end up in agreement anyways so best of luck with your FLUI.

You've waxed eloquently about what it can and will be able to do, but all we've actually seen is a small handful of purpose-built code snippets and your word that they were generated by the transpiler.

The online DSX transpiler has been live since Feb 2018 and anybody can use it so there is no need to take my word for anything. Press 'Compile' and it compiles what its written on the left panel and places results on right panel. Open debugger and you will see the AST written out.
https://spark-heroku-dsx.herokuapp.com/index.html

The problem is that, where JSX was built on a weakly-typed dynamic language like JavaScript, DSX is being built on a strongly-typed static language like Dart.

It makes no major difference at all, like the OOP (Object Oriented Programming) concept and syntax for 'classes'. It's almost identical in typeless Javascript or typed Dart; same can be said for 'if' statement, 'for' statement, etc

it still needs to bring something to the table that is going to convince people to use it.

Apparently already does for 100 people in this ticket; and that's 100 times larger than just me using it; good enough for me.

@cbazza

The online DSX transpiler has been live since Feb 2018 and anybody can use it so there is no need to take my word for anything. Press 'Compile' and it compiles what its written on the left panel and places results on right panel. Open debugger and you will see the AST written out.

I didn't even see that that link was a working example. I've never used herokuapp before and it just looked like a gist or something, so that's on me. :P
(Though I will point out that tinkering with an online sandbox is not the same as testing the transpiler in a more practical environment.)

It makes no major difference at all, like the OOP (Object Oriented Programming) concept and syntax for 'classes'. It's almost identical in typeless Javascript or typed Dart; same can be said for 'if' statement, 'for' statement, etc

You already had to deal with one such difference in child strong-typing. What about attribute strong-typing? What about widgets in different libraries with the same name? What happens if someone makes a widget with more than one nameless positional argument? What happens if we import two libraries that have widgets with the same name? What happens in some scenario that I haven't thought of pops up to further showcase the inherent difference between systems like Javascript and Dart? I have to say, you being so flippant on this discussion point makes me worry about DSX's longevity in a real-world setting.

Apparently it already does for 100 people in this ticket; and that's 100 times larger than just me using it; good enough for me.

Again, that's 100 people who upvoted the issue on the basis of "Consider JSX-like syntax inside dart code". They upvoted because they want JSX, and as you've been so keen to point out, DSX is not JSX. So why else would they want to use DSX? Because inline XML-like UI declaration is "the future"? Again, I just don't see it.
We've already covered JSX in Vue not getting any traction, but there's also the two React alternatives mentioned in the Web Components article you linked: Inferno and Preact. As far as I can tell, they have both failed to make any kind of waves at all in the JS-based web-app development world, despite also natively supporting JSX-like syntax. I really think that people need to have a long and hard look about exactly why people like JSX in React, because by all accounts it just doesn't seem to be because of JSX itself. If that question can be answered, then we can move forward toward "future" innovations rather than just frankensteining that one feature from that one library we liked into everywhere else we personally think it should be.

@escamoteur I'm with you on this one. The 100.

@Bessonov

Sorry, but this isn't a problem. Furthermore, this doesn't make any sense at all. Beside of that, we use JSX with TypeScript.

React wasn't designed for TypeScript. It was designed for Javascript. All the widget definitions, attributes, properties, and everything else was designed to be used in the dynamic environment of JavaScript, so the type safety of TypeScript doesn't introduce any new factors with how JSX interacts with React. This is yet another example of how JSX was designed for a completely different setting than what Flutter is.

@andrewackerman
Why do you think it does matter? JSX is a way to describe interface. It's language agnostic on it's own. Look here. It's not JavaScript. But well, why it can't be done with JSX? (Beside there is no implementation of this (yet))
And.. you know... flow come from fb too:

Flow is a static typechecker for JavaScript.

Please, stop selling arguments for and against extensions you've never use. I use JSX every day and I'm happy with it ATM, although I was very skeptical about it. I can imagine, that JSX evolves in other patterns, like it was with AngularJS.
And maybe this topic helps to find better pattern for Dart? DSX is just one proposal. Look at builder pattern example above or other language tweaks presented here. And, well, maybe your flui is a better way? I don't know. But let's find it out and help to each other to improve their suggestions instead of discussing about bad things in someones else proposal.

I would like to propose close this topic and open new umbrella topic with limited conversation. All proposals to improve the way, how flutter may be used, discuss in own topics objectively with love and without hate.

Yeap, the amount of hate here is epic, just consider this:
There are 3587 open tickets, if you sort them by "thumbs down" you get
1 (this one) with 57 "thumbs down"
3586 (other tickets) with 1 or less "thumbs down"

@Bessonov

Why do you think it does matter? JSX is a way to describe interface. It's language agnostic on it's own. Look here. It's not JavaScript. But well, why it can't be done with JSX? (Beside there is no implementation of this (yet))

It's a way to describe JSX in Javascript (hence the "JS" part of the name). And no, since it's an inlined DST, it is not language-agnostic. And even if it was, that still doesn't make it  the "better choice", since there are plenty of truly language-agnostic DSTs out there that would be woefully inadequate for UI declarations.

And.. you know... flow come from fb too:

Flow is just like TypeScript: a static type checking system for Javascript. It is not a React tool, nor was React designed to be used with it. React is first and foremost a Javascript library, and JSX was designed to be used with React. Whatever secondary tools and utilities get introduced into React development are ultimately irrelevant to React+JSX interoperability.

Please, stop selling arguments for and against extensions you've never use. I use JSX every day and I'm happy with it ATM, although I was very skeptical about it. I can imagine, that JSX evolves in other patterns, like it was with AngularJS.

Please, stop selling arguments for and against extensions you've never use. I use JSX every day and I'm happy with it ATM, although I was very skeptical about it. I can imagine, that JSX evolves in other patterns, like it was with AngularJS.

I have used JSX, and though I do have personal opinions of it, I have deliberately left those opinions out of this discussion. In fact, had you read my previous comments, you would know that I had praised JSX for revolutionizing UI development in React. Other than some mildly tangential comments I've made about the market penetration of JSX as a whole, my arguments have been specifically about JSX in Flutter. And on that topic, there is no prac
Unless, of course,  you've been using DSX every day as well and can enlighten us on the practical advantages of using DSX in Flutter?

And maybe this topic helps to find better pattern for Dart? DSX is just one proposal. Look at builder pattern example above or other language tweaks presented here. And, well, maybe your flui is a better way? I don't know. But let's find it out and help to each other to improve their suggestions instead of discussing about bad things in someones else proposal.

That is what I'm doing. DSX is being proposed as a UI solution for people familiar with JSX. There are key design elements in JSX that were intended to be used for an environment completely different from Dart and Flutter. Those differences need to be addressed for DSX to be successful.  I'm trying to promote constructive discussion and ask the important questions. Yet all the responses I've been getting has amounted to subjective tautology ("JSX is good because it's the future, and it's the future because it's good"), dismissive hand-waving of crucial design points ("DSX does not need to account for differences between JS and Dart because there aren't any"), or just plain hostile ("You obviously don't like JSX so stop talking about DSX").
You do not make a successful product solely with unadulterated praise. It needs to stand up to and account for criticism as well. People showing up and saying "OMG yes please, make DSX", while uplifting, is not helpful. There have been several people throughout this thread that have brought up perfectly valid criticisms of DSX, both with its initial design and with the concept as a whole. And for the most part, many of these criticisms have yet to be directly addressed, with the general attitude being dismissive.
My only fear is that all this unconditional love for JSX is preventing people from viewing DSX objectively. I get why you guys want something like JSX in Flutter, and I can relate - my opinion that Flutter needs a dedicated UI DSL is what lead me to create flui. But if the only people allowed to talk about DSX are the people who have nothing but good things to say about it, then it will fail.

Leave it opened as is because people will continue to open new tickets asking for JSX (as it has already happened twice before).

Leave it open as is because people will continue to open new tickets asking for JSX (as it has already happened twice before).

The difference here is that we would now be able to answer with the following :
"We don't plan on implementing this in dart/flutter for now. But you can take a look at community alternatives [here] and [there] or read [this issue]"
and close the issue as duplicate.

One place for comments and votes and it is here. The request for JSX-like functionality is not going away and the ticket is opened because it needs Flutter tools support (compiler & VS Code IDE) and I have updated the ticket request with this info (first comment). If an enormous number of people starts asking for this, it will give the Flutter team incentive to put resources into it.

Looks like most of the controversy here is not around JSX at this point, but DSX. I'd suggest splitting DSX discussion into it's own thread and leave this one generic to JSX.
In the end DSX is just one way of getting something closer to JSX so we shouldn't be mixing these two discussions in one thread regardless.

That's the longest and pointless Github issue I ever seen.

@cbazza Good job 👍
DSX + 1

@BarryYan, Thank you

Please avoid this kind of comment, be it "+1" or "Thanks".
This sends an email to all subscribers for nothing interesting.

Nothing interesting to you !!!
Please avoid telling people what they can say or do and focus only on what you can say or do.

@cbazza
Dude, it's basic etiquette. Any new message on this thread emails everyone subscribed to it, so it's rude to post comment that doesn't contribute to the discussion because it annoys people for no reason. Basic reactions like "+1" and "Thanks" can be conveyed with a simple thumbs up reaction, so just do that.
That being said, if this thread has really devolved into arguing over whether someone should or shouldn't post a "+1" message, that's a big red flag that all constructive discussion has officially died, and it really should be closed (perhaps permanently this time).

@andrewackerman,
Got it but while you are at it perhaps you should also consider basic etiquette while blasting this thread with your novels (long & fictional writing).

After all your writings you haven't added any value to DSX so I have no interest having a discussion with you on this subject.
Tell me something, do you have answers to your own questions when they are applied to FLUI? Let's discuss FLUI for a bit shall we?

@cbazza

Got it but while you are at it perhaps you should also consider basic etiquette while blasting this thread with your novels (long & fictional writing).

The fact that you refer to my responses that I put a lot of time and effort into being as well-thought-out and unbiased as I can make them as "long & fictional writing" illustrates a lot about your character  and how you are approaching this discussion. I'm trying to promote discussion regarding very real issues surrounding any implementation of JSX in Flutter, while you lambast anyone with any form of contrary opinion. Which of us is the bigger offender of basic etiquette?

The only thing I am "demanding" is that you address the numerous issues brought up by many people regarding DSX with more than either a hand-wave or open hostility. For someone who is proposing a significant change/addition to Flutter's feature set, I feel like that's not an unreasonable expectation.

After all your writings you haven't added any value to DSX so I have no interest having a discussion with you on this subject.

I'm asking you to defend your position. You've repeatedly said that JSX/DSX is the best/future, but have yet to explain how or why. Several people have expressed valid concerns about DSX, but instead of addressing them, you wave it off by hiding behind the counterargument "if you don't like it, don't use it". My "motive" is to get you to answer questions that need to be asked regarding any technical project, first and foremost being why people should ever use it over the alternatives. (And as I have explained before, familiarity is not a good enough reason.)
As far as FLUI is concerned, all I am doing is proposing an alternative solution to the overall problem (UI declarative syntax for Flutter) while requesting that people do the same to it that I am doing to DSX - offer sincere and constructive criticism. I am not saying that FLUI is objectively better than DSX - I'm proposing an alternative formed from a different approach to UI development and asking people to form their own opinions.
(I'd also like to point out that, other than my initial mention where I was proposing a possible alternative approach to GUI representation, the only times I've ever even talked about FLUI is when you brought it up. So how does it makes sense that my ulterior motive is to promote it when you are talking about it more than I am?)

Tell me something, do you have answers to your own questions when they are applied to FLUI? Let's discuss FLUI for a bit shall we?

FLUI is not DSX - it doesn't have to answer every question that I posed to you regarding DSX because many of them are specific to DSX's design. That's not to say that it doesn't have its own set of questions that need to be answered, though, and no, I don't have all those answers. That's why I value critical discussion - FLUI/DSX aren't going to stand up to the court of public opinion unless they can survive getting raked across the coals a couple times. This is not the appropriate place to discuss FLUI though. If you want to discuss FLUI at length, the project has its own issue board, so feel free to post there.
In closing, instead of responding to criticism, you've instead been defensive and evasive, so much so that you are directly responsible for the two separate occasions (approaching three) where this thread had to be temporarily closed due to things getting too heated. So I'm going to break from "etiquette" and say this once: shelf your ego, stop interpreting criticisms as personal attacks, and answer the important questions. Either that, or make peace with DSX never getting off the ground.

andrewackerman Good job 👍

1

@andrewackerman

Good job

Dude, you get a compliment from @jstansbe which conveys a lot more information than a thumb up and you thumb down on the compliment?
Obviously you didn't take my hint on length to heart but don't come to conclusions about my character because you don't know me at all.

The fact that you refer to my responses that I put a lot of time and effort into being as well-thought-out and unbiased as I can make them

That I appreciate and I read all your 'long writings', answering everything: no way, but when I answer properly you don't understand my answer and concludes that I am being dismissive.
It is obvious to me that you are not very experienced with JSX, you really don't understand how it works. So instead of doubling down just own it and I'll explain it in more detail. For example JSX & DSX only does the following 2 transforms (mentioned several times before):
(1)
<A property="a" />
    becomes
new A(property: a)

(2)
<A property="a">
  <B />
  <C />
</A>
    becomes
new A(property: a, children: <Widget>[new B(), new C()])

Everything else is handled by the host language, so for example: how does it handle import of components named the same; answer: host language. I am not being dismissive, it is the way it is designed and the source of it's strength. You see if you separate markup and programming into separate files, you start to duplicate the programming inside the markup with simple constructs for 'if', etc. You end up building a declarative programming language inside the markup that can never be as powerful as the main programming language. So by bringing the markup into the programming language you have the best of both worlds and that's the power of JSX/DSX.
Notice above on (2) that the transform hardcoded <Widget> and that's not always the case, so now you can specify that if needed as discussed before. Look at the transforms and now all symbols come from source or can be specified so there won't be some major magic gotchas in the future.

while you lambast anyone with any form of contrary opinion.

That's not true, you can have contrary opinion but you can't claim something true when I can proof otherwise.

For someone who is proposing a significant change/addition to Flutter's feature set, I feel like that's not an unreasonable expectation.

But that's the thing, I wanted the Flutter team to implement DSX but then I did it so what they need to implement is generic stuff that doesn't depend on DSX and DSX is not the only beneficiary. The browser js engine supports source maps which enabled an ecosystem of new languages in the browser that transpiled to js; it enabled the creation of Dart !!! and several others (Coffeescript, Typescript, Reason, etc). Dart could do the same now and benefit from the ecosystem that it helps bring up, all boats rise.

I'm asking you to defend your position.

I've already done it many times and the conclusion is that Plain Dart or DSX comes down to user preference; and the important thing is to provide option instead of forcing people one way.

first and foremost being why people should ever use it over the alternatives.

I would use DSX because I prefer it, like spaces or tabs, type definition before or after the variable name. There is no point fighting for it, just accept that people have different preferences; there is more than 1 programming editor out there right?

familiarity is not a good enough reason

Just your opinion, why do we use "if" statements in almost every language, 'for' statement, 'class', and now 'asyn/await'.

This is not the appropriate place to discuss FLUI though. If you want to discuss FLUI at length, the project has its own issue board, so feel free to post there.

Very good, now you gained my respect.

you are directly responsible for the two separate occasions (approaching three) where this thread had to be temporarily closed due to things getting too heated.

Thing is even if it gets closed again it won't stop people from asking for JSX-like capabilities.

shelf your ego, stop interpreting criticisms as personal attacks, and answer the important questions.

I have no ego but I do have short temper so there is no mistaking when someone pisses me off (it comes out right away). Not to offend you but your questions were not important.

Either that, or make peace with DSX never getting off the ground.

You are not the meter used to measure success and you don't know what I am up to.

Ok this conversation has gone well beyond the kinds of discussions that we consider acceptable in the Flutter community, and so I'm going to lock this thread and close the bug. Please consider reading https://flutter.io/design-principles/#conflict-resolution for more details on how we behave here.
The next step if anyone wants to contribute code to address this issue would be to come up with a design for how to do build system integration such that we can have code generation work with Gradle, Xcode, hot reload, and integration with existing apps. If anyone is interested in working on this, please don't hesitate to reach out to me. Otherwise I expect this is something we'll work on early next year. Once we have a mechanism to do that, solutions like DSX will be easy to integrate into the Flutter ecosystem. We may even find solutions that should be integrated by default. In the meantime we're also working on improvements to Dart's syntax to see if we can make UI expressions even easier to write.
I would like to ask that people do not open new bugs on this topic unless there is something very constructive and new that is worth bringing up.


Probable Spelling Mistake for Version Number in README

https://github.com/Sidpatchy/InventoryRollback-Continued/blob/f8440f57877a6ce0f2c843d585d28a1543489521/README.md?plain=1#L10
I think it should say 1.5.3 and not 2.5.3, because 2.5.3 doesn't exist yet.

See #7
Good catch, thank you!


Support reading Secp256k1KeyIdentity from pem

Is your feature request related to a problem? Please describe.
Currently, it's not possible to read a Secp256k1KeyIdentity in agent-js via pem. This is possible in agent-rs.
Describe the solution you'd like
Support reading pem format in Secp256k1KeyIdentity.
Describe alternatives you've considered
Custom parsing solutions, and using to/fromJSON, which seems incompatible with agent-rs.
Additional context
This work came out of dscvr.one, where we're migrating some existing javascript to rust. A key issue was sharing keys in a format that worked for both agent-js and agent-rs. We've implemented a solution using the https://github.com/starkbank/ecdsa-node package, which supports reading from a key pair generated by openssl. This format is also compatible with agent-rs. If this is within the scope of this package, I can submit a patch.

I've debated it for a while - I'm hesitant to support fromPem and fromSeed, out of the concern that it might encourage risky patterns of UX flows where users copy around high-sensitivity secrets and increase the risk of clipboard and phishing attacks.
The benefits of supporting Node.js application developers probably outweigh those concerns though, and I think that you can go ahead with that PR, @ncpenke

Thanks @krpeacock. I ran into an issue: the ecdsa-node package we used is pure javascript, and doesn't yet have typescript bindings.
Three approaches come to mind:

Add a minimal set of typescript bindings to ecdsa-node. But I didn't see any other @types used as dependancies, so wasn't sure if this was something you were intentionally avoiding.
Add DER decode logic for private keys and the necessary PEM parsing code.
Abandon this issue in this package, and add support to import JSON keys to agent-rs.

Our primary use-case in dscvr, which could be useful to the broader community is interoperability between agent-rs and agent-js, so 3 would be sufficient to achieve this as well. Please let me know what you think would be the best. Thank you!

We aren't deliberately avoiding @types - we just try to keep our dependencies minimal, and most of the packages we've gone with had typescript support.
I think the bigger issue would be new node-specific dependencies.
@ncpenke an easier workflow would probably be to add seed phrase import support to Secp256k1KeyIdentity, and to ensure it matches dfx identity import --seed-file. What do you thinkg?

I think that sounds reasonable


Not really an issue but need advice

Hello I am tring to use your allegro API
Everything is working fine until i am trying to do DoCheckNewAuctionExtRequest
For after sales i do $afterSalesServiceConditions = new AfterSalesServiceConditionsStruct($impliedWarranties, $returnPolicies, $warranties);
But how to use $fields = new ArrayOfFieldsvalue($datafield_decoded);
What data and structure we should Put
$datafield_decoded = array(item_array("fid"=>1, ... ),item_array("fid"=>2, ... )) etc => return NULL
if I try to bypass  the new  ArrayOfFieldsvalue and put directly my  $datafield_decoded on $fields place
i have error Fatal error:  Uncaught SoapFault: Nie podano parametru wymaganego dla wybranej kategorii. (Kategoria - fid: 2) , FID 2 is well provided with int value...
Thanks for advice
And big thanks for this API :-)

Hello,
For ArrayOfFieldsvalue you should use collection of FieldsValue objects.
Unfortunately, PHP SoapClient has some limitations, so sending such big requests using these objects can end with fail.
I use simple array requests when using new auction methods. Allegro documentation shows how to do it: https://allegro.pl/webapi/documentation.php/show/id,41

HI
Many thank for your answer
I am not performing as you in PHP
So it is working like that
$param = json_decode( $datafield); //$datafields = AJAX POST of array(array("fid"=>xx, "fvalue"=>"", ect...))
$fields = new ArrayOfFieldsvalue();
$fields->setItem((array)$param);
this for the others newbies like me
BR

Yeah, good to know is that ArrayOfFieldsvalue implements ArrayAccess, so you can treat it like array. Eg. you can do it like that:
$fields = new ArrayOfFieldsvalue();
$fields[] = new FieldsValue();
$fields[] = new FieldsValue();


Ab gatsby parks page v1

Description
This PR includes the following proposed change(s):

BC parks info page - first cut  (sorry very big PR)

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Refactoring / Documentation
[ ] Version change

if your change is a breaking change, please add breaking change label to this PR
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Does the change impact or break the Docker build?

[ ] Yes
[ ] No

If Yes: Has Docker been updated accordingly?

[ ] Yes
[ ] No

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] New and existing unit tests pass locally with my changes

First cut for BC parks page, there  will be more changes coming.


Vite 4 support?

Having trouble installing it with Vite 4. Error below:
$ npm i vite-ssr -D
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/vite
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@vitejs/plugin-vue
npm ERR!     dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/vite-ssr
npm ERR!   dev vite-ssr@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! /home/lau/.npm/_logs/2023-01-15T10_09_05_724Z-eresolve-report.txt

npm ERR!  PRs are welcome!

We are really looking forward to vite 4 support

Please try the new v0.17.0

Got the following error when starting the app after build:
Server started: http://localhost:3000
(node:37951) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/home/.../dist/server/main.js:1
import { defineComponent, ref, onMounted, inject, createApp, useSSRContext, resolveComponent, withCtx, createTextVNode, toDisplayString } from "vue";
^^^^^^

SyntaxError: Cannot use import statement outside a module

So I have to change this json file manually:
// ./dist/server/package.json
{
  "main": "main.js",
  "type": "commonjs",
  "ssr": {
    "assets": [
      "assets",
      "error.html",
      "favicon.ico",
      "static"
    ]
  }
}

Change "type": "commonjs", to "type": "module",.
Then everything is working perfectly.
Could you please update that?
Thanks for your hard work!

@frandiox Got the following error when starting the app after build:
Server started: http://localhost:3000
(node:37951) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/home/.../dist/server/main.js:1
import { defineComponent, ref, onMounted, inject, createApp, useSSRContext, resolveComponent, withCtx, createTextVNode, toDisplayString } from "vue";
^^^^^^

SyntaxError: Cannot use import statement outside a module

So I have to change this json file manually:
// ./dist/server/package.json
{
  "main": "main.js",
  "type": "commonjs",
  "ssr": {
    "assets": [
      "assets",
      "error.html",
      "favicon.ico",
      "static"
    ]
  }
}

Change "type": "commonjs", to "type": "module",.
Then everything is working perfectly.
Could you please automate that?
Thanks for your hard work!

@frandiox thanks for fixing that and making the new release! It now works perfectly and I don't see any more errors :-D


Implement scroll during selection

Can be quite hard to realize...

It’s been a while. I felt that the startup window had become nicer since I don't have to find the editing file. By the way, I meant that you can start dragging canvas from right dragging at a point outside of selected objects. However, I'm not sure that this is a good way.

Do you mean that the selection should remain during the drag?
Actually it is a good point because it will allow to expand the actual selection by items which were not visible before the canvas has been dragged...

do you mean that the selection should remain during the drag after right click?

Yes, but this seems a bit strange operation. This is my only idea to drag objects to far place. Maybe there is better way.

done in branch


Finalize EF Migration strategy

Dropping SQLite support
A hard decision but one worth making.  I've supported Sqlite throughout v1 alpha and betas, the benefits of using Sqlite include:

out of box user can just run the app, there is no db requirement whatsoever on users part, it just works.
it works out of box on all the OSes, Win, Linux and Mac.
for user running just a personal blog sqlite is sufficient, no need to spend extra on sql server.

However, supporting both Sqlite and SqlServer means I cannot easily maintain migrations in my code, because there has to be one set of migrations to keep for each db vendor I support, this is messy.
Coming back to supporting only Sql Server, means user needs to have Sql Server pre-installed on their machine, and possibly adjust the connection string, before running the app.  This is a minor inconvenience compared to having migrations in my code, benefits include:

easy upgrade, user can just run the new version of the app and all new db changes are applied through migration automatically
if other decides to add a new app or plugin, they can add their migrations along, user running that code base will automatically have the necessary db tables etc ready for the new app or plugins.
one less db vendor to support; sqlite migration has limitations, e.g. rename a column, which I don't have to live with

How to support multiple DbContext
So far I'm able to use multiple dbcontextes, one for Fan named CoreDbContext and one for Fan.Blogs named BlogDbContext, however I have to carry an over-all dbcontext FanDbContext in Fan.Web which is needed to do migration in startup.
Every time I add a new app or plugin I have to update startup.cs, this is not really convenient, I need to find a way to use reflection and do this part automatically.

I have dropped support for sqlite, I can concentrate on development more, don't have to switch between sql server and sqlite to test both.
I have come back to a single dbcontext that controls every entity in the entire solution, but this time I used reflection to find and load these entities, mappings dynamically.
To add a migration, open Package Manager

select "src\Fan" as the Default project
Add-Migration FanSchemaV1
This will add a new folder "Fan/Migrations" with a migration named FanSchemaV1

ctrl + f5, the site is up running with db automatically created

Add a property to Post class, say public int SortOrder { get; set; }
Add-Migration FanSchemaV1_Add_SortOrder
This will add a new migration.

ctrl + f5, site is up running with Post table have new column SortOrder added automatically in db

Any changes to db can now be down with Add-Migration and just run the app.  If I want to get the sql script running behind each migration, I can run Script-Migration [-Idempotent] to review.