Just not working, even with latest update

I am sorry, but when i first tried this a few days ago it worked, then mysteriously it stopped working a few hours later (I think Sublime3 updated); I have tried the things posted here for chmod and such forth which didn't help, then I noticed it just updated and i tried again, still no luck, I have uninstalled and reinstalled the package and still not working.
I get this whenever I try to do an intellisense popup:
response: "/Users/coderangerdan/Documents/Projects/c#-vnext/SimpleTest/Program.sln"
request: http://localhost:51103/autocomplete
======== request params ========
 b'{"WantSnippet": true, "WantReturnType": true, "column": "11", "WantMethodHeader": true, "wordToComplete": "", "filename": "/Users/coderangerdan/Documents/Projects/c#-vnext/SimpleTest/Program.cs", "buffer": "using System;\\npublic class Program\\n{\\n\\tpublic static void Main()\\n\\t{\\n\\t\\tConsole.WriteLine(\\"Hello World\\");\\n\\t\\tConsole.WriteLine(\\"testing 23qeq\\");\\n\\t}\\n}\\n", "line": "7"}'
Traceback (most recent call last):
  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 529, in urlopen

  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 334, in _make_request

  File "./http/client.py", line 1065, in request
  File "./http/client.py", line 1103, in _send_request
  File "./http/client.py", line 1061, in endheaders
  File "./http/client.py", line 906, in _send_output
  File "./http/client.py", line 844, in send
  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connection.py", line 155, in connect
    conn = self._new_conn()
  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connection.py", line 134, in _new_conn
    (self.host, self.port), self.timeout, **extra_kw)
  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/util/connection.py", line 87, in create_connection
    if err is not None:
  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/util/connection.py", line 78, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/omnisharp.py", line 38, in run

  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/poolmanager.py", line 153, in urlopen
    kw['assert_same_host'] = False
  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 595, in urlopen

  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 595, in urlopen

  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 595, in urlopen

  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 575, in urlopen

  File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/util/retry.py", line 271, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
OmniSharp.lib.urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='localhost', port=51103): Max retries exceeded with url: /autocomplete (Caused by ProtocolError('Connection aborted.', ConnectionRefusedError(61, 'Connection refused')))

Can you give any advice, sorry to ask but I haven't been able to find a solution. I even tried running OmniSharp.exe with mono from the package folder and I also get an error (don't know if its related):
00000044 Using solution path /Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/PrebuiltOmniSharpServer
00000045 Using config file /Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/PrebuiltOmniSharpServer/config.json
Monodoc documentation tree could not be loaded.System.InvalidOperationException: Sequence contains no elements
  at System.Linq.Enumerable.First[String] (IEnumerable`1 source) [0x00000] in <filename unknown>:0
  at MonoDevelop.Projects.HelpService.InitializeHelpTree () [0x00000] in <filename unknown>:0
00000996 OmniSharp server is listening

Looks like you are trying it for vnext apps.
You will have to clone the git repo and use the roslyn branch
On 8 April 2015 at 21:37, Dan Petitt<EMAIL_ADDRESS>wrote:

I am sorry, but when i first tried this a few days ago it worked, then
mysteriously it stopped working a few hours later (I think Sublime3
updated); I have tried the things posted here for chmod and such forth
which didn't help, then I noticed it just updated and i tried again, still
no luck, I have uninstalled and reinstalled the package and still not
working.
I get this whenever I try to do an intellisense popup:
response: "/Users/coderangerdan/Documents/Projects/c#-vnext/SimpleTest/Program.sln"
request: http://localhost:51103/autocomplete
======== request params ========
b'{"WantSnippet": true, "WantReturnType": true, "column": "11", "WantMethodHeader": true, "wordToComplete": "", "filename": "/Users/coderangerdan/Documents/Projects/c#-vnext/SimpleTest/Program.cs", "buffer": "using System;\npublic class Program\n{\n\tpublic static void Main()\n\t{\n\t\tConsole.WriteLine(\"Hello World\");\n\t\tConsole.WriteLine(\"testing 23qeq\");\n\t}\n}\n", "line": "7"}'
Traceback (most recent call last):
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 529, in urlopen
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 334, in _make_request
File "./http/client.py", line 1065, in request
File "./http/client.py", line 1103, in _send_request
File "./http/client.py", line 1061, in endheaders
File "./http/client.py", line 906, in _send_output
File "./http/client.py", line 844, in send
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connection.py", line 155, in connect
conn = self._new_conn()
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connection.py", line 134, in _new_conn
(self.host, self.port), self.timeout, **extra_kw)
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/util/connection.py", line 87, in create_connection
if err is not None:
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/util/connection.py", line 78, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 61] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/omnisharp.py", line 38, in run
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/poolmanager.py", line 153, in urlopen
kw['assert_same_host'] = False
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 595, in urlopen
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 595, in urlopen
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 595, in urlopen
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/connectionpool.py", line 575, in urlopen
File "/Users/coderangerdan/Library/Application Support/Sublime Text 3/Packages/OmniSharp/lib/urllib3/util/retry.py", line 271, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
OmniSharp.lib.urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='localhost', port=51103): Max retries exceeded with url: /autocomplete (Caused by ProtocolError('Connection aborted.', ConnectionRefusedError(61, 'Connection refused')))
Can you give any advice, sorry to ask but I haven't been able to find a
solution.
--
Reply to this email directly or view it on GitHub
https://github.com/OmniSharp/omnisharp-sublime/issues/158.

Nope just a simple nine line file:
using System;
public class Program
{
public static void Main()
{
Console.WriteLine("Hello World");
Console.WriteLine("testing 23qeq");
}
}

with a solution?
do you see mono-sgen in activity monitor when a csharp file is activated?
kill sublime, kill mono sgen processes, open sublime, open a cs file, check mono sgen is running, try formatting a document to see if it works

Ah, I found a package.json file (dunno where that came from, perhaps yeoman) which must have made it think it was a vNext version; I deleted that and changed my sublime project to "solution_file": "./" and it now works.
Thanks for your help, and much apologies for wasting your time!

no worries
On 8 April 2015 at 22:04, Dan Petitt<EMAIL_ADDRESS>wrote:

Closed #158 https://github.com/OmniSharp/omnisharp-sublime/issues/158.
--
Reply to this email directly or view it on GitHub
https://github.com/OmniSharp/omnisharp-sublime/issues/158#event-276627227
.


Update README.md

added telegram group link for community part

@mrfarhadir thanks for your contribution. I noticed there is only one member in the group. Is this true?

@veelenga I mean, if you join it, it's already two :smile:
Good idea to have a Telegram Chat, but I'd prefer to join one moderated by known members of Crystal Community :thinking:

@mrfarhadir if you feel comfortable to moderate it, please suggest/announce the room to the community first.


fix blackhole

https://github.com/hirak/prestissimo/pull/85#issuecomment-218063966

Coverage remained the same at 95.616% when pulling 3ab0390ca55ec137017a30b956f297870492d37d on fix-blackhole into e78a097b5bcf7abf44563a09f67482e38d0cec4b on master.


Detailed information on senders/recipients

The visual representation of results could be improved if email addresses, listed under "most received from" or "most sent to", respectively, would be clickable to show details for that address. For example, a click on the first entry in "most received from" would visualise (activity over time, daytime, weekday, month, temporal distribution etc.) data for that address.

Thank you for this request. So in fact, this would be an additional filter for contact specific stats. Since I'm using Chart,js to generate the charts, I have to see if there's a click listener for single elements in a bar chart. It's definitely possible to implement this as a drop-down, like the folder filter.

Sounds good, thanks for looking into it.

This is now implemented with #262. Please test it and let me know, if there are any issues. Have a nice sunday!


Generic sort functions to be used with set_dupsort() or set_compare().

Use it like this (for every type that implement FromMdbValue and Ord):
db.set_compare(lmdb::sort::<u64>);
db.set_dupsort(lmdb::sort_reverse::<u64>);

It would be great to have a test case for it as there is a unsafe conversion from Ordering to u8, even though it's very unlikely will change soon

Please see my second commit. There, I assert that the ordering conversion is as expected.

As you use u64 as an example how to use those functions may I also ask you to add a doc comment for them with a note that LMDB has a smart internal integer sorting (it doesn't depends on size of integer), which means if the key has a fixed size it's preferred to set DbIntKey flag instead of setting a custom sort function?
I apologize I haven't though of it earlier.

I will add a doc comment, but I don't know much about LMDB's internal integer sorting. I only expect it to work for usize and probably u32. Would it work for u16 or u8, too? Where is this documented in LMDB?
Btw, I found out that when you want to sort keys that are > u64 (for example a (u64, u64) tuple), you can do that by encoding it as big-endian and use the string sort of LMDB. This was before you added set_cmp() and set_dupsort() functions, which would be the prefered way.

I've actually expected it to work only with u32/u64 depending on system but here is a clarification, see MDB_INTEGER section

which would be the preferred way

Tuples are interesting case, I'd try to go with LMDB builtin int comparison


Support native import css/json modules

import sheet from './myModule.css' assert { 'type': 'css' };
import sheet from './config.json' assert { 'type': 'json' };

these are valid imports in Chromium/Chrome. It would be nice if we could support, right now the "assert" keyword is an unknown one.
Here's a dynamic import example:
const sheet = (await import('./myModule.css', { assert: { type: 'css' } })).default;

More info: https://v8.dev/features/import-assertions
Thanks!

Also adding this:
It's in stage 3.
https://tc39.es/proposal-import-assertions/

Sounds good to me. (As per JSHint's policy on new language features, this became in-scope when the proposal entered "stage 3" of TC39's process, so we're actually lagging behind on this one.)
As always, I'll be happy to help anyone interested in contributing.


Add vibration on parts merging

It would be a good feedback, improves a bit accessibility, and not much work to implement.
The Gamepad object of each controller gets referenced here

done


Coda account already imported but cant list

How to reproduce:

On host: Start coda with docker and wait for sync.
On host: coda accounts import -privkey-path ~/keys/my-wallet
On docker: coda  accounts list

😢 You have no tracked accounts!
 You can make a new one using `coda accounts create`

On docker:Try to import again inside docker gives following situation.

root@71969f04cbc4:~# coda accounts import -privkey-path /keys/my-wallet
Key already present, no need to import : B62qpMeanu57n1RFXh2ADkzcezBNCbspmQYJHGpBQvuC1XLEYDrTs5b
root@71969f04cbc4:~# coda accounts list
😢 You have no tracked accounts!
You can make a new one using `coda accounts create`

Hotfix:
Maybe team should write something whether this wont have any unwanted side effects:
Go to /home/<yourUser>/.coda-config/wallets/store
Backup what is inside and delete it.
Now on docker:
coda accounts import -privkey-path /keys/my-wallet
coda accounts list

This is a dup of #6110

Please comment on #6110 if you want to discuss further. Thanks!

Please comment on #6110 if you want to discuss further. Thanks!


IGNITE-6171: + LongJVMPauseDetector, + longJVMPausesCount and longJVM…

…PausesTotalDuration properties of IgniteMXBean.

The ticket is resolved. Closing PR


Change Homepage on npm

The homepage points to the old organization.
Can we change the URL?

Good


Model monitors don't print to file

I tried both screen and model monitors inside a notebook. The screen monitor worked fine, but the model monitor didn't seem to be able to write to file.

I just fixed this in the example notebook. The original way we had this directory structured had the notebooks in a folder, but now they're in the root, so all the paths were off. This should be fixed now, but let me know if you're seeing the bug in other contexts.

I just fixed this in the example notebook. The original way we had this directory structured had the notebooks in a folder, but now they're in the root, so all the paths were off. This should be fixed now, but let me know if you're seeing the bug in other contexts.


More detailed and specific machine info detection in TKG

TKG checks machine info through MachineInfo.java. At the current stage, not all machine info commands are tailored based on platforms.  We would like to improve this by identifying which commands work on which platform and conditionally use different commands on different platforms. An example is https://github.com/adoptium/TKG/blob/5d83f85f235f5c9e1a7426a712173351f3dea281/src/org/openj9/envInfo/MachineInfo.java#L175

related: https://github.com/adoptium/TKG/issues/45


[Bounty] Activity Classification Algorithm

Step 0: Submit a plan on how you will implement this.
Step 1: List of activities is mentioned below (there can be more than this. ) Each activity can be further associated with few labels with which a matching algorithm is run. Create a test data for the text that you wish to classify as following activities.

Politics
Comedy
Sports
Movies
Reading
Coding
Programming
Designing
Trading
Gaming
Shopping
Podcasts
Music
Medicine
Government
Planning
Job Hunting
Marketplace (Shopify/Facebook Marketplace)
Sitcoms
TV Series

Step 3: Write a python module to classify any given text with these activities. You can create new labels for each activity.
Step 4: Submit the PR for this, write function on this file https://github.com/Kleo-Network/connect-backend/blob/main/app/celery/tasks.py
VIDEO Exaplaining the Bounty - https://www.loom.com/share/fcac9bc2742d437692fc60d5ca0e35a4?sid=c2495a45-87a1-459f-abfd-520ed430b4b4
Total Bounty - 200 USDC
Reviewer - @vaibhavgeek

hello @vaibhavgeek , you can create a bounty on Bountyhub, it's integrated into github, (a bot will comment to let other people know that there is a bounty) and if no one solves your bounty you can retract it and get your money back. It is also one way to let people know that the bounty amount is already available.

At first I need to collect test datas. For that:

Collect data from sources like news for political, sports, and many more, linkedin for job hunting, facebook workspaces for shopping (product listing), etc.
For those whose data can't be collected easily will be making artificial data using llms by writing a python script.

After collecting the labelled data, will use methods like cosine similarity to train and test it.

Can you share detailed tech stack plan for classification, creating the test dataset is not super important task but just to validate the classification task that the code does.  How you think about classification shows your understanding of this task.
Do share a detailed plan about the same.

Hi @vaibhavgeek
After a long research and few POCs we have implemented 3 approaches for this Activity Classification Algorithm. They are as followed.
Requirements for this implementation

We will have some activities array which we can modify at any time.
Also we will be given one passage having pre-processed webpage-content.
We will classify that passage return the most relevant activity from activities array.

Keyword Extraction Approach
Explanation :

We first extract keywords from the passage.
Then embed the passage and the extracted keywords.
Now we will do similarity between keywords and the activity.
Return the activity with the maximum score. High score mean more relevant.

Tech Details / Model Info :

sentence_transformer model  :  all-mpnet-base-v2
KeyWord Extraction : keybert

Extra details are on this card.

Zero Shot Classification - Transformers Pipeline Approach
Explanation :

We will have create a zero-shot-classification pipeline with the model of choice.
Then pass the passage, activities array and turn the multi_label flag false for better accuracy.
This will provide output of array of each object containing the activity with it's relevancy score.
We will take the first one as it is the highest.

Tech Details / Model Info :

pipeline_name : "zero-shot-classification"
model_name : "MoritzLaurer/mDeBERTa-v3-base-mnli-xnli"

Extra details are on this card.

Flag Embeddings ReRanker Approach
Explanation :

This model works like question answer ranking.

You provide a pair of question and answer, this model will rank them based on relevancy.

So, here we are giving an array like this for every passage.
[[is this related to {activity1}, passage], [is this related to {activity2}, passage], ...]
Now we will get the scores for each activity related to passage, from that we can get the highest one which is most relevant.
This is how we are doing this classification here.

Tech Details / Mode Info :

tokenizer = AutoTokenizer.from_pretrained(BAAI/bge-reranker-v2-m3)
model = AutoModelForSequenceClassification.from_pretrained(BAAI/bge-reranker-v2-m3)

Extra details are on this card.

After analysing above implementations we came to conclusion that

Fine Tuning :

We would require to fineTune these preTrained models on our data.
But as we don't have real data right now, we can't fine Tune them.

Initial Algorithm Implementation

So, initially we should go with the Keyword Extraction Approach.

Future Scope

In Future when we have some decent amount of data to fine tune the models.

We can pre-process that data.
Label that data manually ideally.
Then fine tune the mentioned models.
Use them for our implementation.

Can you share the test data you used to determine the accuracy?

Sure, Here is the test Data which I have benchmarked all of these approaches.
[
  {
    "TestCase": 1,
    "Content": "Global Trading Platform - Trade Stocks, Forex, and Commodities. Home, Markets, Trading Tools, Education, Support. Live Market Updates: Real-time data on stock prices and currency exchange rates. Educational Webinars: Upcoming sessions on trading strategies. Economic Calendar: Key financial events and announcements. Risk disclosures and regulatory compliance information.",
    "Activity": "Trading",
    "Reasoning": "This content is centered on trading activities, providing services and information directly related to financial trading. The classifier should assign this content to 'Trading' based on the focus on stock markets, trading tools, and investment education."
  },
  {
    "TestCase": 2,
    "Content": "Innovate Design Studio - Crafting Visual Experiences. Portfolio, Services, Blog, About Us, Contact. Showcasing high-quality images of recent design projects. Our services include branding, web design, illustration, and UI/UX design. Case studies provide detailed accounts of successful design projects. Blog posts cover design trends, tutorials, and industry insights. Connect with us on Behance, Dribbble, and Instagram.",
    "Activity": "Designing",
    "Reasoning": "The content is specific to designing, focusing on creative services and showcasing design work. The classifier should assign 'Designing' as the activity due to the emphasis on design services and industry terminology."
  },
  {
    "TestCase": 3,
    "Content": "CineWorld - Your Gateway to the Latest Movies. Now Showing, Coming Soon, Trailers, Reviews, Tickets. Featuring upcoming blockbuster movie posters with 'Book Now' options. Top Picks: Editor's choice of must-watch films. User Reviews: Audience ratings and comments. Exclusive Interviews: Videos with directors and actors. Sign up for our newsletter and connect with movie industry partners.",
    "Activity": "Movies",
    "Reasoning": "This content revolves entirely around movies, including showtimes, reviews, and interviews. The classifier should assign the activity 'Movies' based on the entertainment-focused content."
  },
  {
    "TestCase": 4,
    "Content": "Department of Environmental Protection - Official Government Site. Programs & Services, Laws & Regulations, Newsroom, About DEP, Contact Us. Updates on environmental policies and initiatives. Public Notices: Information on upcoming hearings and public comment periods. Resources include access to permits, forms, and environmental data. Government logos, privacy policy, and accessibility statement.",
    "Activity": "Government",
    "Reasoning": "The content is specific to government activities, focusing on environmental policies and official services. The classifier should assign 'Government' as the activity due to the official nature and governmental context."
  },
  {
    "TestCase": 5,
    "Content": "Eventopia - Your Event Planning Partner. Services, Portfolio, Testimonials, Blog, Get a Quote. Showcasing beautifully decorated venues with happy attendees. Our services include wedding planning, corporate events, and social gatherings. Client testimonials from satisfied customers. Blog articles offer tips on event themes, budgeting, and vendor selection. Contact information and social media links.",
    "Activity": "Planning",
    "Reasoning": "This content is dedicated to planning, specifically event planning services. The classifier should assign 'Planning' as the activity based on the focus on organizing events and providing planning resources."
  },
  {
    "TestCase": 6,
    "Content": "SportsHub - All Things Sports in One Place. News, Live Scores, Teams, Players, Shop. Live Score Ticker with real-time updates on ongoing matches. Latest News: Breaking updates in the sports world. Featured Teams: Profiles and statistics. Merchandise Store: Official jerseys, equipment, and memorabilia. Subscribe for newsletters and access to premium content.",
    "Activity": "Sports",
    "Reasoning": "The content is entirely about sports, offering news, live scores, and merchandise. The classifier should assign 'Sports' as the activity due to the comprehensive sports-related content."
  },
  {
    "TestCase": 7,
    "Content": "Stadium Architects - Designing the Future of Sports Venues. Projects, Services, Insights, About Us, Contact. Showcasing time-lapse videos of stadium constructions. Featured Projects: Details on recently completed stadiums and arenas. Services include architectural design, structural engineering, and sustainability consulting. Insights: Articles on trends in sports venue design. Awards and recognitions in architectural excellence.",
    "Activity": "Designing",
    "Reasoning": "Although the content intersects designing and sports, the primary activity is designing, specifically architectural design. The classifier should assign 'Designing' as the activity due to the focus on design services and architectural projects."
  },
  {
    "TestCase": 8,
    "Content": "Collector's Paradise - Trading Cards Galore. Home, Categories, Auctions, Blog, Community. Featured Categories include sports cards (baseball, basketball, football), movie memorabilia (posters, scripts, limited edition items), and gaming cards (Pokémon, Magic: The Gathering). Upcoming Auctions: Schedule and featured items. Collector's Blog: Tips on valuing and trading collectibles. Membership signup and customer support links.",
    "Activity": "Trading",
    "Reasoning": "Despite involving sports and movies memorabilia, the primary activity is trading collectibles. The classifier should assign 'Trading' as the activity based on the emphasis on buying, selling, and auctioning items."
  },
  {
    "TestCase": 9,
    "Content": "City Planning Department - Shaping the Future of Our City. Services include urban planning, zoning, and development approvals. Public meetings and hearings schedule. Resources on city development projects. Contact information for community feedback.",
    "Activity": "Government",
    "Reasoning": "This content represents a government department focused on urban planning. The classifier should assign 'Government' as the activity due to the official context and government-related planning services."
  },
  {
    "TestCase": 10,
    "Content": "Financial Planning Advisors - Secure Your Future. Services, Our Approach, Resources, Blog, Contact Us. Images of families consulting with financial advisors. Our services include retirement planning, investment strategies, and wealth management. Resources: Market reports and investment calculators. Blog posts: Articles on financial trends and tips. Certifications and affiliations with financial regulatory bodies.",
    "Activity": "Trading",
    "Reasoning": "While 'planning' is mentioned, the context is financial planning related to investments and trading. The classifier should assign 'Trading' as the activity due to the financial and investment focus."
  },
  {
    "TestCase": 11,
    "Content": "National Film Board - Preserving Cinematic Heritage. Home, Collections, Education, News, About Us. Free streaming of classic films. Collections: Archives of historically significant movies. Educational Programs: Workshops and resources for schools. News: Government initiatives supporting the film industry. Government insignia and links to cultural departments.",
    "Activity": "Movies",
    "Reasoning": "Even though it's a government site, the primary activity is movies. The classifier should assign 'Movies' as the activity, focusing on cinematic content and film preservation."
  },
  {
    "TestCase": 12,
    "Content": "Coach's Corner - Training Plans for Athletes. Training Programs, Nutrition, Blog, About Us, Contact. Images of athletes in training sessions. Customized training plans for runners, swimmers, and cyclists. Nutrition guides: Meal plans to enhance performance. Success stories: Testimonials from athletes. Subscribe to our coaching newsletter.",
    "Activity": "Sports",
    "Reasoning": "The content is centered on sports training and athletic performance. The classifier should assign 'Sports' as the activity due to the focus on sports-related coaching and training programs."
  },
  {
    "TestCase": 13,
    "Content": "Creative Minds - Designing Innovative Products. Our team specializes in product design, from concept to prototype. Services include industrial design, 3D modeling, and usability testing. Portfolio showcases award-winning designs. Blog articles discuss the latest in design technology and materials.",
    "Activity": "Designing",
    "Reasoning": "This content is focused on product and industrial design. The classifier should assign 'Designing' as the activity due to the emphasis on creating and developing new products."
  },
  {
    "TestCase": 14,
    "Content": "Strategic Business Planning Services - Charting the Path to Success. Offering corporate planning, market analysis, and strategic development services. Case studies of successful business transformations. Resources include planning templates and industry reports.",
    "Activity": "Planning",
    "Reasoning": "The content revolves around business planning services. The classifier should assign 'Planning' as the activity due to the focus on strategic planning and organizational development."
  },
  {
    "TestCase": 15,
    "Content": "Sports Analytics Inc. - Data-Driven Insights for Athletic Performance. Services include performance analysis, game strategy optimization, and player scouting reports. Case studies showcase how analytics improved team outcomes. Blog posts on the latest trends in sports data science.",
    "Activity": "Sports",
    "Reasoning": "This content is dedicated to sports analytics, focusing on enhancing athletic performance through data. The classifier should assign 'Sports' as the activity due to the sports-specific application of analytics."
  }
]

Sounds good, create a pull request. The code needs to be called from https://github.com/Kleo-Network/connect-backend/blob/main/app/celery/tasks.py and so ensure that.
Test the function independently in a file before adding to tasks.py. I will merge the PR and close the PR. Awesome work.

@vaibhavgeek
The PR for this issue #30  Has been merged on 30, Sep, 2024.
Need to close this issue. Please close this issue at your convenience. Thanks.

Awesome work! Closing this now.


luci-app-dawn: Bug fixes for JavaScript implementation

Some bug fixes and a small improvements that were discovered after the initial implementation of the JavaScript version of luci-app-dawn:

Correctly show multiple APs per client in the hearing map
Display correct name of all APs in the hearing map
Show if client is connected to the network in the hearing map. This replaces the column for Stations Connected, which is not a property of a client but of an AP, and is available still in the network overview.
Display both hostname and MAC address for clients/APs
Convert spaced to tabs in dawn-common.js for consistency

@PolynomialDivision As mentioned in https://github.com/openwrt/luci/pull/6656#issuecomment-1793549325 some bug are present in the current implementation. This new pull request fixes this.
The request to (also) display MAC address next to host names is new functionality. From my perspective a hostname means more than a MAC address, so it's now implements as hostname (MA:CA:DD:RE:SS). But is could easily be swapped if, for many use cases, the MAC address is more meaningful, and sorting on MAC address makes more sense.

Perhaps you could also address the situation where the dawn service is not currently running? (please see #6448 for ideas).

The same issue was reported in https://github.com/openwrt/luci/commit/ea8c0aa2a1a1ff9f29ffd452049a7b749298ed17#commitcomment-131699709 The JavaScript version presents the error as:

Which I think is already way better than the 500 server error previously.
But the same question as there: is there a use case where DAWN is regularly not running when accessing a DAWN page? Or is it OK to display such an error message, and the user should go an investigate why it is not running.
Do you know of any LuCi applications that handle such an error correctly? Then I could copy the code from there. As far as I can tell now, the RPC implementation in LuCi just displays a fixed error message without any way to customise it.

You can use the LuCi.rpc.list() method to check if a given object or procedure exists in ubus, prior to calling it.
Something like this:
function isDawnRPCAvailable() {
    return rpc.list("dawn").then(function(signatures) {
        return 'dawn' in signatures && 'get_network' in signatures.dawn && 'get_hearing_map' in signatures.dawn;
    });
}

return view.extend({
	handleSaveApply: null,
	handleSave: null,
	handleReset: null,

	load: function() {
		return Promise.all([
			checkDawnRPCAvailable().then(dawn.callDawnGetHearingMap),
			dawn.callHostHints()
		]);
	},

	render: function(data) {
		const dawnHearingMapData = data[0];
		const hostHintsData = data[1];

		if (!dawnHearingMapData) {
			return E([
				E('h2', _('Dawn service unavailable')),
				E('p', _('Unable to query the dawn service via ubus, the service appears to be stopped.'))
			]);
		}

		...

An even simpler approach is wrapping the call to dawn.callDawnGetHearingMap() into L.resolveDefault(), like this:

	load: function() {
		return Promise.all([
			L.resolveDefault(dawn.callDawnGetHearingMap(), null),
			dawn.callHostHints()
		]);
	},

Only downside is that there will still be an error logged to the console.

Thanks @jow- for providing this detailed information. I'll implement this in the current pull request.

Nice thanks a lot! Would be nice if you could implement @jow- feedback in upcoming PR.


Remove User.REQUIRED_FIELDS from fields attribute on user serializers

User.REQUIRED_FIELDS is meant to be used only by createsuperuser management command
Resolves: #136

Coverage remained the same at 96.341% when pulling 97ed566c94f558bfbddeea02ba1adf25d6b9af9c on KaczuH:ISSUE/136 into e10d9162031c49e3b4a31afa0072a928b7c014e0 on sunscrapers:master.

But won't this break if the User.EMAIL_FIELD isn't set?

Coverage increased (+0.009%) to 96.35% when pulling a1d253846898ea2eb2c8f6ca7ccffbc7923b44f8 on KaczuH:ISSUE/136 into e10d9162031c49e3b4a31afa0072a928b7c014e0 on sunscrapers:master.

Coverage increased (+0.009%) to 96.35% when pulling 27a989e356e79b7668ea58cb5c49a4294316de12 on KaczuH:ISSUE/136 into e10d9162031c49e3b4a31afa0072a928b7c014e0 on sunscrapers:master.

Coverage increased (+0.03%) to 96.372% when pulling 1d1dcb8910764bab68ce944b78d299921eb6efc2 on KaczuH:ISSUE/136 into e10d9162031c49e3b4a31afa0072a928b7c014e0 on sunscrapers:master.

Coverage decreased (-0.4%) to 95.946% when pulling 3c10ff892044ce4fe6e7ee1485b2c9d259602e20 on KaczuH:ISSUE/136 into e10d9162031c49e3b4a31afa0072a928b7c014e0 on sunscrapers:master.

Coverage increased (+0.05%) to 96.396% when pulling 2eface6b2e1cc8b30a9427fc631e2853d32b607f on KaczuH:ISSUE/136 into e10d9162031c49e3b4a31afa0072a928b7c014e0 on sunscrapers:master.

@KaczuH can you update this for djoser-2.0 if it's still relevant? I'm closing this as it targets the legacy version.


source_dest_check not applied

I have issues
The source_dest_check (AWS: SrcDestCheck) on ec2 instance subnets are not applied to my setup, while I think this should be the default case. This is not externalized either.
I'm submitting a...

[x] bug report
[ ] feature request
[ ] support request - read the FAQ first!
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
After a successful terraform apply, I have the eks up and running,  but when I check Source/Destination Check
(https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck)
it is set to TRUE.
If this is a bug, how to reproduce? Please include a code sample if relevant.
I'm using the module with worker_groups_launch_template like this:
    {
      name                    = "spot-1"
      override_instance_types = ["m5.large", "m5a.large", "t3a.large", "m5ad.large"]
      spot_instance_pools     = 4
      asg_max_size            = 8
      asg_desired_capacity    = 3
      kubelet_extra_args      = "--node-labels=node.kubernetes.io/lifecycle=spot"
      public_ip               = true
      bootstrap_extra_args    = "--use-max-pods false"
      suspended_processes     = ["AZRebalance"]
    }

No, other worker group or template defined.
What's the expected behavior?
The source_dest_check should be FALSE.
Are you able to fix this problem and submit a PR? Link here if you have already.
No.
Environment details

Affected module version: 12.2.0
OS: linux (manjaro)
Terraform version: v0.13.1

Any other relevant info

Source/Destination check is not configurable for auto scaling instances. It defaults to true. This is a limitation of the AWS API (ASG, Launch Template, Launch Configuration) and not something controllable by this module.
You might want to try doing something in the userdata script at start up. e.g.
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --source-dest-check "{\"Value\": true}"

Thanks @dpiddockcmp , I was not aware of that.


upgraded to netstandard2.0

Upgraded project files to target to netstandard2.0, inlcuding deps

It appears the Travis build fails, could you please take a look at why that happens?
Thanks!

Yeah, I had to update the deps on samples as well. The builds are now ok.
Cheers,
Rafal
On Fri, Sep 15, 2017 at 12:06 PM, Radu Matei<EMAIL_ADDRESS>wrote:

It appears the Travis build fails, could you please take a look at why
that happens?
Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/radu-matei/websocket-manager/pull/44#issuecomment-329739994,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcaxaS2jpJbzVMOw7Ep-c3vcuXig1iIXks5sikwggaJpZM4PYRm_
.

--
Cheers,
Rafal

Merged into temp branch


tspan tags counted as characters for masking

Running the pre-compiled windows 64 bit version.  I see the issue when placing text between arrows.  An area around the text is masked out (arrowheads erased).  That area grows and shrinks based on the total length of the text string.
If I add  repeatedly the white, masked, area before and after the text extends erasing progressively more of the graph.  Presumably only the actual non-control characters should be counted.

Duplicate Closing....

Duplicate Closing....


Add a dropdown to specify the number of results per page

Resolves #648, #658

Redefined the search partial
Added a select dropdown to set the results count
Fix pagination parameter

Also curious about your seed data @MohamedAsan! Was this a CSV spreadsheet you imported into Terrastories or did you populate via Rails?

Also curious about your seed data @MohamedAsan! Was this a CSV spreadsheet you imported into Terrastories or did you populate via Rails?

@rudokemper I just executed a script in rails console to populate the model data using faker gem to generate to random data


Terminal is very slow , it is lagging a lot  and does not display output immediately especially when I am running http methods and gets stuck

I was working on Rest API in python using flask.
Terminal gets stuck when I try to run any http method, it is very slow  and doesn't print any statement inside my method.

It looks like your report is missing some important information, See this wiki page for more info on how to report actionable terminal issues.
/label "needs more info" terminal

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!


Add initial ES6 symbol support

This is a prototype for an implementation approach where Symbols are duk_hstrings with a specific byte prefix which cannot occur for valid (extended) UTF-8 strings. The existing internal string concept is essentially taken a step further to support ES6 Symbols. There's no new internal type for Symbols as such, and the C API sees Symbols as just strings.

[x] Code change for symbol support
[x] Fix compiler warnings
[x] Fix Reflect.keys()
[x] Testcase support
[ ] Fix perftest coercion issues
[ ] Check key coercion for duk_def_prop() and other property calls
[ ] Website
[ ] Internal documentation
[ ] Wiki pull for symbols howto (should cover the C API aspects especially)
[ ] 2.x migration notes
[ ] Releases entry
[ ] Read through pull comments and add cleanup issues to #1120

Looking at the footprint change which is roughly 0.5kB now, the final footprint impact would probably be around 1-2kB. It may be large enough to need a config option to turn off; symbols would still work if you constructed them from C code, but the constructor, Symbol.for() etc bindings would be removed (similarly to disabling buffer objects, which still leaves behind the basic buffer types etc).

Scanned through ES6 specification for:

All "symbol" references
All "string" references
All "@@" references (for well known symbols)
For ToPropertyKey and IsPropertyKey references

Scanned code base for:

duk_is_string() (duk_to_string() and variants are not an issue: they reject symbols already)
duk_get_string() and variants
duk_require_string() and variants
DUK_TAG_STRING
DUK_TYPE_STRING and DUK_TYPE_MASK_STRING
DUK_TVAL_IS_STRING

Relevant places in Dukape code are either fixed or marked FIXME. This coverage is probably not 100% but close to it.

So assuming I understood well-known symbols correctly this time, there are essentially three kinds of Symbols in ES6:

Global symbols, Symbol.keyFor(sym) returns its description. Knowing its description you can create/access the symbol using Symbol.key(). For Duktape there's no global registry, but rather an identical symbol is created whenever the same description is requested which satisfies the conceptual registry requirements as far as I understand.
Local symbols, each call to Symbol() creates a unique new instance. There's no way to recreate the same Symbol using standard APIs. For Duktape C code has that ability if it happens to know the underlying Symbol representation, and 1:1 buffer-to-string conversions allow that. May or may not have a description.
Well-known symbol, essentially a local symbol but shared across code realms so it can't be "unique". As a practical matter well-known symbols must be created with a fixed internal suffix which won't overlap with the internal suffix used for dynamically created local Symbols.

This raises a few C API issues. The simplest approach for now is to provide no API for Symbol creation: one can simply create them as byte strings following the documented internal string format. But if API calls (or macros) are added:

There needs to be an API call to create a global symbol with a given description.
There needs to be an API call to create a local symbol with a given description (or NULL), and an automatic unique suffix guaranteed to be unique across at least that Duktape heap (preferably others).
There also needs to be an API call to create a local symbol with a given description (or NULL) and a forced unique suffix, so that user code can also create its own "well known" symbols with a known internal suffix. Otherwise the user would need to pass the symbols across Duktape threads manually rather than creating them on the spot.

All in all I'll probably leave the C API out of the initial merge - there's no C API for internal symbols either. But at least C string initializer macros would be very nice to hide the representations in a more version compatible manner.

Now the branch disables the Symbol built-in bindings for stripped builds (also minimal because minimal configuration is ES5 only). There's still a +500-600 byte impact from symbol support.
Note that disabling symbol built-ins doesn't disable symbol handling as such, and one can still create symbols from C code directly into their byte representation and they behave like symbols should, to the extent this pull supports them.
Most likely there needs to be two separate defines: one for symbol support in general (that can be dropped entirely) and another for the presence of the built-in symbol bindings. Let's see if that's possible in a reasonable manner.

I'll focus on this for the next few days and choose one implementation option or the other - there will then be a symbol baseline (with no explicit C API) in master to work against. Changing the implementation approach (from duk_tval tag or not) can be done in master, as the difference is not visible to Ecmascript code (except in very contrived situations).

One part of ES6 I'm having a hard time wrapping my head around is "code realms".  Best I can tell the closest analogue in Duktape would be to create multiple contexts - since each realm gets a unique global object, etc.

That should be pretty close I think. Duktape doesn't actually track "code realms" as such: threads created into the same global space just happen to have the same built-in object pointers so they behave as if they live in the same space. But there's no internal mechanism preventing a thread that mostly shares the same pointers but with one pointer (say Number built-in) replaced with something else. There's no API to do that but as far as internal state goes, that's the case now.
It may be necessary to formalize that arrangement somehow, e.g. so that a duk_hthread explicitly points to some "code realm" object which would "own" the built-in objects. Any changes to the built-ins e.g. during sandboxing setup would then propagate to any threads that already exist within that realm.

That indirection will make some call sites worse (specifically those that deal with built-in objects) but it will also make duk_hthread smaller because the built-in table is not copied to every thread in the same global space.

Apparently objects can be passed between realms, otherwise there would be no reason to explicitly specify that well-known symbols are shared.  So yeah, the closest thing we have right now seems to be creating multiple threads, each with its own global object.

That symbol sharing works itself out quite naturally in this pull (or any approach where symbols are internal strings): a globally registered symbol (GlobalSymbolRegistry conceptually) has a fixed representation which is just a prefix and the symbol name. So, if the same symbol is registered by name (Symbol.for()) anywhere, they'll get the same duk_hstring for their internal representation.

A slight correction: Symbol.for() globally registered symbols are distinct from well-known symbols:
> Symbol.iterator
Symbol(Symbol.iterator)
> x = Symbol.for('Symbol.iterator')
Symbol(Symbol.iterator)
> Symbol.iterator == x
false

But they can still be handled the same way: if they have a fixed representation, they'll map to the same duk_hstring anywhere in the same heap.

I assume the Symbol.for() registry is also shared between realms?

Yes, http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.for:

The GlobalSymbolRegistry is a List that is globally available. It is shared by all Code Realms.

Thanks, that makes sense why Symbol.for() exists then.  I couldn't figure out what purpose it served since within a single thread/realm you can easily pass a regular symbol around to share it.  But if you want to access a symbol from a different realm it's indeed more convenient to just do Symbol.for("name").

It's also convenient in some cases to create a symbol with a known name using Symbol.for(name) rather than pass the symbol around.

Been working off and on in fixing issues in the pull. There are a bunch of FIXMEs still left but I hope to get this into mergeable order early next week. That doesn't mean it will be merged though, but it's then time to figure out if this merge is good enough as a first implementation for 2.x. It's then possible to rework it in an API compatible manner within 2.x but more than likely reworking the whole approach would also impact the API and would be most natural in 3.x.

Getting close: not many actual fixes needed for this to be mergeable as a MVP... :)

Good to hear.  Looking forward to having Symbol support in master, then I'll have to find all sorts of new and wonderful ways to abuse it. :)

@svaarala What is the convention for well-known symbols?  Is it easy to reference them from C code as, e.g. "\xa0" "toStringTag"?

Yes, C code will be able to create local symbols, global symbols, well-known symbols, and "hidden" symbols (= previous internal keys). Hidden symbols are \xFF prefixed as a carryover from 1.x, and will be different in that they're actually hidden from even Object.getOwnPropertySymbols(). They can be accessed through C code and are intended for hidden state.
But I thought I'd add some API macros to create those forms without needing to use direct hex escapes, e.g.:
#define DUK_SYMBOL_HIDDEN(desc) ("\xff" (desc))
#define DUK_SYMBOL_GLOBAL(desc) ("\x80" (desc))
/* ... */

so that one could then:
duk_push_string(ctx, DUK_SYMBOL_GLOBAL("scoreCounter"));

For unique symbols it may be useful to have a C API to create one, because there's a unique part that might not be best filled by a macro. One simple way to do that in a macro is to use a __FILE__ ":" STRINFIGY(__LINE__) string as the unique suffix, which should work in most cases reliably. But the resulting symbol strings would be rather long so an API call is probably preferable.

A bit unrelated but regarding stashes, once symbols are implemented, and #979 merged, there's not much need for the stash objects if one is using hidden symbols. Hidden symbols would be reliably isolated from Ecmascript code, so that:

Global stash could be hidden symbols on the global object.
Thread stash could be hidden symbols on the thread object.
Heap stash still needs its own object.

There are also downsides to this, e.g. the need to use a hidden symbol where previously a plain string key on the stash object would be isolated from C. So, this is something to consider after 2.x.

Alright, no more FIXMEs in the code or tooling. That doesn't mean the code is finished or correct, but no obvious things anymore. I'll work on testcases next - that'll probably reveal something that needs fixing but other than that this is slowly coming to completion.

I could check out this branch and do some manual testing too - there are a few use cases I have in mind involving private properties that are currently awkwardly handled using closures.

That'd be great - I'll be improving the testcases for maybe a day or two so there's good time.

There's still the possibility of not merging this branch but opting to use a different approach, e.g. where symbols are a distinct internal type. The testcases in this branch would help do so more quickly than it took to develop this approach. Also the code diff indicates where the symbol related changes are needed.
However, the alternatives are looking quite unappealing at present:

This approach requires essentially no mandatory C API changes because symbols are strings. Small additions might be useful (e.g. duk_is_symbol() and maybe a primitive to push a unique local symbol).
Existing internal properties become "hidden symbols" and are not exposed via e.g. Object.getOwnPropertyNames(). But they still otherwise behave like symbols (typeof etc) which is nice.
There's no need for an additional internal type or type tags.
Ecmascript code doesn't really see the difference between the approaches, so changing it later is not difficult (for Ecmascript code).

So, this approach makes sense to me for Duktape 2.x. If it turns out a different approach is better, it would be relatively easy to change for Duktape 3.x -- that would mean breaking API changes, but since there are very few API changes here, the calling code upgrade cost is not that much higher overall.

Found some warnings:
duk_js_ops.c(526): warning C4101: 'tv_tmp': unreferenced local variable (compiling source file ..\src\shared\duktape.c)
duk_js_ops.c(670): warning C4101: 'rc': unreferenced local variable (compiling source file ..\src\shared\duktape.c)
duk_js_ops.c(677): warning C4101: 'rc': unreferenced local variable (compiling source file ..\src\shared\duktape.c)
duk_js_ops.c(688): warning C4101: 'rc': unreferenced local variable (compiling source file ..\src\shared\duktape.c)
duk_js_ops.c(697): warning C4101: 'rc': unreferenced local variable (compiling source file ..\src\shared\duktape.c)
d:\src\minisphere\msvs\duk_bi_object.c(697): warning C4700: uninitialized local variable 'enum_flags' used

Unreferenced variable warnings are surely harmless, but "uninitialized local variable used" is concerning.

There are still warnings - I haven't cleaned that part up yet. That enum_flags warning has been fixed and should disappear if you pull again.

Yeah, I wasn't too surprised by the warnings - I know this is still a WIP :)  If not for the enum_flags warning I would have kept quiet.

I'll fix the warnings when I do a code read-through tomorrow. That enum_flags thing was an actual bug (caused by a line being dropped in a rebase) BTW :)

I'm off to sleep for a bit - let me know how it turned out :) If you want to create symbols from C code, this should be relatively up-to-date w.r.t. the internal formats: https://github.com/svaarala/duktape/pull/980/files.

One thing I noticed looking through the symbol doc is this bit:

Symbols are visible to the public C API as strings: duk_is_string() is true, duk_get_string() returns a pointer to the symbol internal string representation, etc.

What of duk_require_string()?  As an API consumer using duk_require_xxx() to validate arguments, I'd want it to throw a TypeError.  duk_is_string() being true is a bit inconvenient too, for the same reasons.

Hm, I don't think this is intended behavior:
duk> String(Symbol.toStringTag)
= "Symbol(Symbol.toStringTag)"
duk> Symbol.toStringTag
= undefined

I notice Symbol.iterator is currently commented out in builtins.yaml.  Since iterators are duck typed, could that symbol be enabled?  For built-in objects such as Array it would be undefined, but I could still define it on my own objects.

What of duk_require_string()? As an API consumer using duk_require_xxx() to validate arguments, I'd want it to throw a TypeError. duk_is_string() being true is a bit inconvenient too, for the same reasons.

duk_require_string() accepts symbols now - same as it does for internal strings at present. I know that's a bit inconvenient, but it would also be weird if symbols had DUK_TYPE_STRING' but wouldn't be accepted by duk_require_string()`.
Regarding String(Symbol.toStringTag) coming out as "undefined" in an interactive session, that's a consequence of using JX for console stringification. Since symbols are not allowed in JSON and JX doesn't serialize them either, the result is undefined. The result is a symbol though:
duk> typeof Symbol.toStringTag
= "symbol"
duk> String(Symbol.toStringTag)
= "Symbol(Symbol.toStringTag)"

Re Symbol.iterator: sure, I'll add it. I did enable a few other symbol properties for testing them out, e.g. Math[Symbol.toStringTag] is set just to see that the properties come out right through tooling. I'll add Symbol.iterator too.

@fatcerberus So this pull uses the approach where C API doesn't know symbols as such - they are strings because they behave like strings for property access. This carries over the Duktape 1.x behavior into symbols: Duktape 1.x internal keys already behave like that, they're just strings as far as C code is concerned. I know that's not ideal but it's also not changing how the API works, although it's maybe more exposed to users if they deal with symbols more than with internal keys.
Adding a duk_is_symbol() to the API would allow user code to distinguish symbols from other strings. But changing duk_is_string(), duk_get_string(), etc, would make the API a little bit weird: duk_get_type() would return DUK_TYPE_STRING for symbols but duk_get_string() etc would not accept them.
The reason why adding a type tag is not straightforward is that there are a lot of small implications from that. I'll write out some of that in a bit, so you'll get a better idea why it's not as straightforward as one might them.
The main issue comes from using duk_hstring also for symbols, but then having a separate type tag for them. That's not an issue when unpacking a symbol from a duk_tval. But after that, packing a duk_hstring back into a duk_tval needs a symbol check to figure out the correct tag. Not using duk_hstring for symbols would be very awkward for property code because it passes around the untagged string pointer which would no longer work; it would also mean string table changes because the same byte representation may be used by both a string and a symbol if they're actually distinct types.
Also using a separate API tag for symbols but duk_hstring internally for both symbols and strings means that you can no longer duk_push_string() arbitrary byte sequences. If they have a symbol representation, that push must either throw or produce a tagged symbol value (so that duk_is_string() would be false right after a duk_push_string()), neither very ideal.
The cleanest conceptual change would be a separate public tag, a separate internal tag, and a separate internal heap type (say duk_hsymbol) for symbols. But the downside of that is a lot more footprint, and awkwardness in the property access code which must genuinely deal with two different key types. When symbols are duk_hstrings the property code is almost unaware of symbols; it just needs to take symbols into account when coercing the property key, and it can then use duk_hstring as is.
One somewhat odd approach would be to add a duk_hsymbol internal type but with the exactly same struct as duk_hstrings use. However, their duk_heaphdr tag could be different so that (1) they can be used as duk_hstrings anywhere, but (2) they can also be distinguished as symbols independent of their byte representation. I'll have to mull over this a bit if it makes sense or not.
So in summary, I like that this pull keeps the Duktape 1.x behavior. I would like for the C API to be more symbol friendly, but what I particularly want to avoid making a hasty API choice without having time to experiment with it. The merit with the approach in this pull is that there's no conceptual change from existing behavior.

Ok, the branch now has the following:
A placeholder for JX/JC serialization so that it's more intuitive (if not clean) in the console. I'm not sure if this should stay or not, and if JX/JC should in general serialize enumerable symbols (doesn't now):
duk> Duktape.enc('jx', { [Symbol()]: 'foo' })  // not serialized as property keys now
= "{}"
duk> Duktape.enc('jx', Symbol.for('foo'))  // but is serialized as value
= "{\"_sym\":\"\\x80foo\"}"
duk> Duktape.enc('jx', { prop: Symbol.for('foo') })
= "{prop:{\"_sym\":\"\\x80foo\"}}"

This makes it more intuitive for your case:
duk> Symbol()
= {"_sym":"\x81\xff0-2\xff"}
duk> Symbol.for('foo')
= {"_sym":"\x80foo"}

No "pretty" JX syntax yet. On the upside, you can see the internal representation quickly there :-). JX and JC syntax is the same for now.
Symbol.iterator is present:
duk> Symbol.iterator
= {"_sym":"\x81Symbol.iterator\xff"}

Regarding JX/JC serialization:

For serialization it's not a big deal to serialize symbols as e.g. {_sym:"<internal representation>"}, with _sym for JX and "_sym" for JC (to keep it JSON compatible).
For deserialization actually parsing a string representation into a symbol instance is a bit dangerous. In particular, that would allow for creation of hidden symbols using JX parsing.

It might be a bit odd if the JX serialization/deserialization was asymmetric, i.e. symbols wouldn't parse back as symbols but rather as some kind of objects (say, {_sym:"something"}). Then again, functions already do that and they JX-serialize as {_func:true}. Maybe symbols could behave similar to that in JX.
The other major alternative is that symbols are entirely ignored by JX and JC, just as they are in JSON, because they're not considered "visible" properties and values. The side effect of this is a bit weird behavior in "duk" console, at least for now, because it uses JX for formatting eval results.

I wasn't suggesting to go to the trouble of an all-new type tag etc.  I just want an API like duk_require_string() that throws if it encounters a symbol because despite the concrete representation being a string, from Ecmascript point of view it's not one and it doesn't make much sense to pass a symbol as e.g. the handle of a map engine entity... :)
If you want to keep the existing string APIs alone that's fine, but then maybe we could have also duk_require_nonsymbol_string() or something?

For JX, I guess it would be okay to allow it to reconstitute symbols if the sandboxing pull (I don't remember its number) is also merged?

duk> Reflect.ownKeys(o).length
= 0
duk>

ownKeys() is defined as a union of getOwnPropertyNames() + getOwnPropertySymbols().

I wasn't suggesting to go to the trouble of an all-new type tag etc.

That was discussed earlier in this pull so that's why I brought it up.

I just want an API like duk_require_string() that throws if it encounters a symbol because despite the concrete representation being a string, from Ecmascript point of view it's not one and it doesn't make much sense to pass a symbol as e.g. the handle of a map engine entity... :)

Right, but I think you're not accepting that the C API doesn't recognize symbols and you're trying to apply the Ecmascript type model to the C API. That's logical of course, but the only API model that would really work with that is an explicit symbol type in the API. Anything else, at least as far as I've been able to figure, will lead to some inconsistencies.
For example, if duk_require_string() throws on a symbol, it means that you can duk_push_string() and then say duk_require_string() and it will throw, depending on what data you pushed.
It will also mean that duk_get_type(ctx, -1) == DUK_TYPE_STRING may still mean duk_require_string(ctx, -1 ) throws which is highly confusing.
But how do you deal with internal strings in your current calling side code? You're already most likely accepting internal strings where ordinary strings are intended?

If you want to keep the existing string APIs alone that's fine, but then maybe we could have also duk_require_nonsymbol_string() or something?

It's not so much that I want to leave it alone, but to me it seems that changing the current contract (where e.g. duk_get_type() == DUK_TYPE_STRING is 1:1 equivalent to duk_require_string() not throwing) would be a change for the worse.
But adding a duk_require_nonsymbol_string() would be possible, and the internals actually already do that. The potential trouble there is that if the implementation approach is changed, there's API cruft to deal with.
So my main point really is that with Duktape 1.x code you're already dealing with internal strings somehow. There's absolutely no change in that respect, only that symbols are treated like internal strings are treated in Duktape 1.x. In other words, C code should just deal with them like any other property keys as far as almost any operation is concerned.
I understand it makes it harder to validate string arguments. But that's already the case in Duktape 1.x. And while I agree it's not ideal, this pull isn't making things any worse. I'd particularly like to avoid adding API bindings that get pulled because they are too quickly thought out and baggage going forwards. So any new bindings added due to symbol support need to be carefully thought out so that they're stable against tweaking the representation.

True, but before this pull typeof(internalString) was still "string" :) (also if one pretends the nonstandard bindings don't exist there's at present no way to create one from Ecmascript code)
I do see what you're getting at with the inconsistencies, so no worries there.  Like I said I'm fine with the existing APIs being kept the way they are, I just want a convenience function that only accepts non-symbol strings.  For Duktape/C functions which back public API entrypoints (like the minisphere API), aligning with the Ecmascript type model makes most sense.
I guess I'll just go implement that validation helper myself for now. :)

True, but before this pull typeof(internalString) was still "string" :) (also if one pretends the nonstandard bindings don't exist there's at present no way to create one from Ecmascript code)

But that had absolute no impact on C code :-)

I guess I'll just go implement that validation helper myself for now. :)

I'm OK with adding API bindings for checking symbols conveniently as long as we can be fairly certain they won't be awkward baggage going forward. IOW, if the representation changes, they can be supported via macros without breaking compatibility.
I guess duk_require_string_notsymbol() or whatever would be quite easy to support in the end. If symbols get a specific type, that function would then be the same as duk_require_string().
But there's still the overhead of adding API documentation, explaining why they are deprecated etc, so I'd like to keep this set minimal :)
How about adding a duk_is_symbol() specifically? That wouldn't be very convenient for API validation purposes though.

Regarding the internal strings thing: I guess the difference in my mind is that with internal strings, it was generally safe (ignoring sandboxing concerns) to assume you would never get passed one.  Ecmascript code can now create symbols, so the landscape has changed so to speak.
To answer your question, duk_is_symbol() would be fine - I could then write the validation logic on top of that.

Right, but Ecmascript code can create internal strings in Duktape 1.x quite easily by decoding some data (say base64) and coercing it to string. So it's not necessarily very difficult to do by accident.
But I know what you mean: now that "normal" code is supposed to do so, it'll be more common.
My only real concern is that merging this in for 2.0, and adding a bunch of API bindings without feeling them out carefully, runs the risk of doing API mistakes that can only be undone in 3.0.

Added a note on test coverage (and fix) for Reflect.keys().

My only real concern is that merging this in for 2.0, and adding a bunch of API bindings without feeling them out carefully, runs the risk of doing API mistakes that can only be undone in 3.0.

That's understandable.
I think duk_is_symbol() is a pretty safe bet in this regard - it remains relevant even if (hypothetically) the internal representation of symbols were to change later on.

Also adding a bunch of provisional bindings tagged experimental is an approach used before. But I don't think it will be much less jarring if they're then removed. Experimental API documentation shows up in the API page as a red experimental tag but it should be more prominent to have an actual effect of ensuring that the application writer understands this API may go away.
So that doesn't really seem a very useful approach at least thinking about it right now.

But how about this: I'll leave the API bindings out of this particular pull. We can then see what bindings are really the crucial ones and add them in separate pulls over the next week or so?

Alright, no problem here. :)  Since the internal representation of symbols, in particular the initial byte values, is documented I can write a validation function against that for now.

And thanks for test driving this pull, really appreciate it :)

And thanks for test driving this pull, really appreciate it :)

No problem at all.  If you're wondering what my use case was, it was to avoid the need to use a closure for private properties (yes, symbols are visible through reflection, but that's true even in e.g. C#).  I try to put methods and such on ctor.prototype whenever I can, but that doesn't work when the methods directly reference closure variables.

That's a common use case I'd imagine. For C code having reliably separated hidden symbols is another that will make application writing a bit easier. It will also isolate Duktape's hidden symbols from tampering. But that's actually provided by #979, not this pull.

Ok, Reflect.ownKeys() should now be fixed.

Here's my first foray into using symbols:
https://github.com/fatcerberus/minisphere/blob/master/assets/system/modules/from.js#L85-L116
(Also note that I made good use of Reflect.construct() here allowing me to concisely define query operators--this would have been way more verbose with new!)
That experiment was successful so I'll see later if there are any other places where I'm using closures for private data that could use symbols instead, this way this pull gets more of a workout before merging.

Minor fix: Object.getOwnPropertyDescriptor() didn't accept a symbol Object as a key.

Removed the JX/JC serialization of symbols for now, and moved it to be considered in #1120.

Let me just say though, I find it annoying that one can't do new Symbol("desc").  Function call notation makes me intuitively think that Symbol("foo") returns the same value each time, like Number("812") does.
Maybe Symbol() and Symbol.for() could have been reversed.  But alas, that ship has sailed... :)

I find the Symbol API also a bit unintuitive or at least different from other Ecmascript APIs. I think the idea is to generally avoid Object-wrapped symbols so that while Object(Symbol('foo')) works, the new Symbol('foo') shorthand isn't supported. Otherwise people might use new Symbol('foo') when a plain symbol from Symbol('foo') would suffice.

Performance tests show no visible impact of the additional Symbol flag checks; in fact property accesses seem a bit faster because the ToPropertyKey() now has a fast path (granted, that could also be implemented in master).

@fatcerberus I'll try to do a code read-through and complete the missing documentation tonight (tomorrow at latest). This would then be merge ready, unless some blocker pops up. (If a blocker popped up later, it's still possible to revert in master of course.)

By the way, if duk_require_string() etc. ultimately retain their current behavior of accepting symbols, then that's an important thing to mention in the migration notes I'd think.  Probably a lot of Duktape 1.x code will be using duk_require_string() or duk_is_string() for validation purposes, and that code, if not changed, will now accept symbols as well.

Agree, the description could be something along the lines of:

Symbols behave like internal strings in Duktape 1.x for the C API: they are strings with a specific invalid CESU-8/UTF-8 representation.
Their type is DUK_TYPE_STRING, they test true for duk_is_string(), are accepted by duk_require_string(), etc.
Symbols have non-string behaviors for Ecmascript code, like internal strings did in Duktape 1.x.
However, you're more likely to encounter symbols in C code if you use Symbols in your Ecmascript code base.

Previously you would encounter internal keys if you explicitly created them, or passed them in from sloppy C code - this might have happened e.g. if you passed a ISO-8859-1 string to duk_push_string() as is.

If the C API behavior is ultimately not good enough one approach would be to skip merging this for 2.0.0 release and try to figure out a compatible way to merge this for 2.1.0.
Note that I'm still toying around with C API alternatives. My main concern is finding something that's likely to be workable for a while. The change in this pull has the merit of being patterned after 1.x so there's no real change in the semantics, only a "renaming of concept". Code not using symbols wouldn't be impacted at all essentially.
Anyway, one approach that seems doable (though I'm not overly excited about it) is:

Add a symbol type to the public API, i.e. DUK_TYPE_SYMBOL, duk_is_symbol(), etc. Symbols would be const char * for C code, exposing the internal representation.
Don't add an internal type tag for duk_tval, so that internally symbols are DUK_TAG_STRING and duk_hstring heap type. (Btw, note that C and Ecmascript types are not 1:1 even disregarding symbols: plain buffers and lightfuncs have a specific C type but they appear as virtual ArrayBuffer and Function objects in the Ecmascript side.)
For example duk_is_string() would check for internal tag DUK_TAG_STRING, look up the duk_hstring *, and then check for the symbol flag DUK_HSTRING_FLAG_SYMBOL before returning.
Internal call sites using duk_is_string(), duk_get_type() etc need checking. There are maybe ~50-100 of them so it's some work but still doable. If a call site accepts both strings and symbols, they would then use an internal helper like duk_is_string_or_symbol().
Most internal call sites switch based on the internal tag, so the Symbol semantics implementations in this pull could remain as is (after checking the call sites of changed public string API calls).

This would be a bit more natural and could keep the current internal mechanics, at least for now. The upside would be that the C and Ecmascript API would be in sync type-wise, and it'd be more likely that internals could be reworked (if needed) without needing to touch the API right away.
But there are still some open questions for this approach. For example, what should duk_push_string() do if the string has an internal representation? Perhaps it should throw to prevent a symbol from being created by accident. This would make sense for e.g. sandboxed code, because one wants to avoid accidentally creating internal keys (at least if #979 is not merged).
However, this would break code dealing e.g. with ISO-8859-1 characters or arbitrary byte strings -- code that used to work in 1.x (although quite oddly for the script side).
If symbols are rejected from duk_push_string() one would then need some kind of duk_push_symbol(). Going that route, it'd then actually be natural to hide the internal representation entirely from C code so that symbols would not be const char * but one would push specific symbol kinds (giving their description, and possibly a unique suffix that might be autogenerated), query symbol types, extract symbol descriptions, etc. There's a lot of potential to go overboard here, just to support a single type which isn't all that central to much practical code.
So... concrete, fully fledged API proposals welcome :-)

This API / typing discussions reminds me that it'd be useful to have a detailed type table that provided both the internal and external type tags, related internal structures, etc for all types (including object classes). The Guide has an API oriented "stack types" table but that's not complete enough to work with internals.

I'll think some on the C API over the next few days, but since I can never keep quiet :)

Btw, note that C and Ecmascript types are not 1:1 even disregarding symbols: plain buffers and lightfuncs have a specific C type but they appear as virtual ArrayBuffer and Function objects in the Ecmascript side.

This is true, but the mentioned cases also generally don't affect validation ;-)  In nearly all cases if I accept an ArrayBuffer on the C side, a plain buffer works just as well, and a lightfunc is likewise just as good as a full-fledged function.  It only sometimes makes sense to allow symbols in place of strings.  For example if a symbol is passed in place of a string which is destined for display, the Ecmascript ToString() throwing behavior is then preferred.

By the way, I think a big part of the reason I see the C/Ecmascript barrier so much differently is that, for minisphere, Duktape is my frontend.  So there's a very fine line between C and Ecmascript as control flows seamlessly between the two domains constantly just as part of normal operation.  Thus, the more difficult it is to reconcile the differences in typing between the two sides, the more of a source of pain that becomes for me as an embedder.

This is true, but the mentioned cases also generally don't affect validation ;-)

The situation is indeed reversed in the sense that multiple C types have a single Ecmascript type in the lightfunc/buffer case.
It does affect validation, just in a different way: you're liable to reject a valid type by accident. For example, if you check for a lightfunc, you won't accept a function. Or if you check for duk_is_buffer() you won't accept a buffer object.
The function case works out because duk_is_function() returns true for both; there's no type tag for functions because they're a subclass of objects anyway, so there's no direct clash at the type tag level.
The buffer case somewhat works out if you use duk_require_buffer_data() for example, because that also accepts plain buffers. But there is no "is" checker for that case.

By the way, I think a big part of the reason I see the C/Ecmascript barrier so much differently is that, for minisphere, Duktape is my frontend. So there's a very fine line between C and Ecmascript as control flows seamlessly between the two domains constantly just as part of normal operation. Thus, the more difficult it is to reconcile the differences in typing between the two sides, the more of a source of pain that becomes for me as an embedder.

I can understand that - and the typing differences between the C API and the Ecmascript side are obviously not a goal.
In fact, if the public type and the internal type will become more decoupled, it might be useful to make lightfuncs and plain buffers behave like their fully fledged counterparts in the C API too (besides pushing). So, they'd have duk_is_object() true for example.
The downside of this is that the C API philosophy would then be different: it'd mimic the Ecmascript side more closely, and hide internals that you might sometimes be interested in. Perhaps introspection can then replace some of those use cases, e.g. reveal if a certain value is a lightfunc.

@svaarala No problems so far with the Symbol support by the way - it's been working great.

The thing I've found I really like about symbols is that any symbol created with Symbol() is guaranteed to be unique within its scope.  Thus you never have to worry about someone accidentally overwriting them by accident.
You can also use them for tagging arbitrary objects and likewise not worry about clobbering something on an object you don't own... which now that I think of it could be used to make a WeakMap polyfill... hmm...

I'd advise against trying to create a weak map without the engine supporting weak references directly. It's quite hard to get right.

ES6 WeakMap is interesting in that no reference to the key is created at all, weak or otherwise.  That's why you can't enumerate it.  It actually just creates a strong reference of key -> value, which can be done in pure JavaScript.  The only thing having built-in engine support buys you is the ability to use non-extensible objects as keys.
But anyway, that's unrelated to this pull, just something I thought of is all :)

I'm not sure what you mean: WeakMap keys are objects that must be tracked and be weakly referenced so that the key (and the value) can be collected?

WeakMap keys are not enumerable, so the ES6 requirements can be met simply by storing the value on the key object itself.  This can be polyfilled easily, so long as the key is extensible.

Hmm. So while a single key (object) may be used in multiple WeakMaps, you would just use a separate symbol for tracking the value related to each WeakMap?
But what if the WeakMap itself becomes unreachable? How do you remove the key/values related to that WeakMap stored in the objects which are still reachable?

In other words: WeakMap.set(key, value) is semantically equivalent to key.uniqueProp = value if uniqueProp were invisible to outside code.

I still don't understand how you remove all the uniqueProp properties from objects in the heap if I say weakMap = null and that was the last reference to the WeakMap itself.

You could keep a list of objects in the WeakMap for that purpose - but that would create a strong reference and prevent collection.

No reference is held to the WeakMap itself - uniqueProp is directly assigned the mapped value so that WeakMap.get(key) just means key.uniqueProp.

I know but consider this:
var buf = new ArrayBuffer(8);
var obj = {};
var wm = new WeakMap();  // allocates a symbol S
wm.set(obj, buf);  // sets obj[S] = buf
wm = null;  // remove reference to the *WeakMap* itself
buf = null;

On that last line, the only strong reference left is obj and buf should be collectable.
However, who removes the obj[S] = buf reference? If it's not removed, buf will remain reachable as long as obj itself exists - which may be indefinitely.

Hm, it may prevent the value from being collected if the key outlives it though.  I'd have to check ES6 to see what it says about that case.

I'm quite sure it should be collected - that's the whole point of weak references in a reference graph.

Well, I'll stop derailing the symbol pull discussion now and we can maybe resume this discussion sometime later.

To get the 2.0.0 release finalized the easiest approach (with least rework down the line) would be:

Merge this for 2.0.0 after rebasing
No API changes yet, which has the downsides discussed above and they need some documentation
Compatible API work for 2.1.0 only (there's lot of that left over, like filling in built-in bindings, etc)
Better symbol support for 3.0.0 with maybe symbols exposed in the API

As discussed above this doesn't really change things much for the application unless you want to use symbols specifically (if you do, then you run into some validation use cases which you brought up). If you don't, the important change is that if you push non-CESU-8/non-UTF-8 strings from the C API they may come out as symbols for script code. But in the end I think there are relatively few applications that really do that and rely on specific behavior, and the updated documentation can discourage doing so for compatibility with changes later on.

As discussed above this doesn't really change things much for the application unless you want to use symbols specifically

Not entirely true. :)  As we also discussed above, symbols will be accepted by duk_require_string(), which application writers have to be aware of, particularly when writing Duktape/C bindings.

Not entirely true. :) As we also discussed above, symbols will be accepted by duk_require_string(), which application writers have to be aware of, particularly when writing Duktape/C bindings.

... But I specifically said "unless you want to use symbols specifically"?

In other words, if you do not use symbols, this pull has minimal changes to the way you use the C API. Internal strings are already present, and already accepted by e.g. duk_require_string().

If Duktape is your front end (like in my case) it could be an issue since your end users can now use symbols. :)

Yes, but that would be the case "you are using symbols", would it not, from Duktape feature point of view?

And if you don't like them doing so, -UDUK_USE_ES6_SYMBOL, and they won'.t

The feature is enabled by default, those upgrading to Duktape 2.0.0 may not realize it's even there.  I don't object to the semantics, just worth a strong mention in the migration notes is all I'm getting at.

Haven't I said several times that I agree with it needs to be documented? :)

Disabling the feature by default would also be quite OK.

Sorry, just want to make sure we don't needlessly surprise anyone.  Can you tell I'm an API designer yet? ;)

Anyway, now that that horse is thoroughly beaten to death, glad to hear this is being merged soon, I'm greatly looking forward to playing with this. :)

That merge decision was really my point: either this needs to be merged without C API changes (i.e. symbols behave like internal strings now) or this needs to be postponed to 3.0.0 due to C API changes. I don't see other alternatives; I really want to finalize a 2.0.0 release quite soon. I'm not sure which approach is better unfortunately.
If this is merged, it's easy enough to disable if you don't want the feature. But, the merge obviously creates some technical debt to maybe update the C API later, and will at least require documentation writing in the near future. C code that really wants to use symbols needs to be touched in the 3.0.0 update once more.
It this is not merged, the branch will bit rot a bit before 3.0.0 release (this is probably still quite workable), but there's no option to use symbols until then unless one builds from the branch. On the other hand, no user code will need upgrading because none will exist.
I don't see symbols as a critical feature so I'm fine with either approach as such.

Ah, I see.  I'll think about this some and see if I can provide any input.

I have some backlog for improving some of the internal data structures which are becoming relevant for footprint or performance -- but so far they don't really affect this merge decision that much. I think the API issue is the most important one, i.e. doing two major steps on the feature vs. postponing the feature but doing it in one step.
The +700 byte footprint impact (when the Symbol built-ins are disabled) is somewhat relevant for low memory targets and may need some follow-up, but it's a minor detail overall.

To elaborate a bit, internal data structure changes are a bit difficult to plan ahead because they often affect every area of the code in some way. It's also quite difficult to see beforehand what data structure changes will be necessary as types are added (say, what will WeakMap mean?).
For example, one of the simplification steps not yet made for buffers is that views could back to ArrayBuffers directly (now they back to a plain buffer and point to an ArrayBuffer via a .buffer property). This would probably mean that the duk_hbufobj structure would be repurposed as a "buffer view" structure, while plain buffers and ArrayBuffers would maybe share some common structure (with plain buffers missing a property table).
This has knock-on effects on the public API; in particular, the tagged buffer type would be removed because plain buffers would behave like ArrayBuffers there too. The API would then need some calls to figure out if a value is an ArrayBuffer or one of the view types, etc. Also some of the non-standard ArrayBuffer virtual properties would be affected. ArrayBuffers would lose the ability the have a view offset (which is never possible in the standard obviously). So there's at least a lot of documentation changes involved in the change.
Similarly, if the symbol internal data structure is adjusted down the road, it will have an effect on what API is clean but still aligned with the internals. It feels risky to make API commitments when the internal representation is maybe still going to change; the API commitments made might then be off-sync with the internal representation which causes a lot of trivia work down the line.
So that's why I'm more inclined to either merge this without API changes or postpone the merge altogether until there's enough time to experiment with the representation alternatives and what they mean for the C API.

Here's my proposal: Merge this for 2.0.0 without the API changes, but put it behind a DUK_USE_SYMBOL_SUPPORT define (this is already present) and disabled by default.  This way the feature is kind of experimental, and users have to read the documentation (along with any caveats) before enabling it.  If it's also documented as experimental, that gives a bit more leeway to change this later if needed.

It's okay I think to disable some ES6 features by default because Duktape, even in master, is still "ES5-ish with some ES6 features".  If Duktape were a full ES6 engine then it'd be strange to disable it, but that's not the case yet.

That approach works for me. There's one detail though: even with the Symbol support there is a small impact on the C API because internal properties (even with 0xFF) prefix will behave as symbols for script code. While that's not likely to cause issues, it does interfere with e.g. string coercion of internal strings. So the feature cannot be fully disabled.
It'd be possible to change that so that with the symbols support disabled typeof internalString would be string as before (and not symbol) but that seems a bit of wasted work.

Actually it probably makes sense to leave the typeof for internal strings as symbol even with support disabled since they behave differently than other strings.  Especially if #979 gets merged too.

Right, but I meant that as a shorthand for them getting all the symbol behavior. In particular, String(x) is a TypeError.

I guess that's acceptable.  It's really only an issue if C code pushes such strings, since Ecmascript code can no longer create them by default (?).
By the way I thought about it some more, and the duk_require_string() behavior does make sense if one views the contract as "require something which is compatible with a C string" instead of specifically "require an Ecmascript string".  So I'm willing to concede on that point. :)


Platform.isAndroid & Platform.isIos shortcuts

motivation: allow to turn the Platform.OS === 'android' and Platform.OS === 'ios' into Platform.isAndroid and Platform.isIos which is shorter and well readable.
Test plan (required)
The change is simple. I tested it by modifying the UIExplorer touchables example. I can push that too, if you like.

By analyzing the blame information on this pull request, we identified @grabbou and @dmmiller to be potential reviewers.

hey @vonovak! not a bad idea, my only concern here is that I don't think it belong within react-native itself. If you want to use these shortcuts you can build them easily on top of the existing Platform.OS constant. additionally, as more platforms are added to react native, we would need to include those, and these platform specific files need to be aware of the full set of platforms. eg: Platform.ios.js would need isAndroid, isWindows, isIos, isUbuntu, isOsx, etc..
for this reason, I think it is best to build a library to do this if you find it useful, or just some utility function inside of your app. 🎸


⚠ RPC server - Figment Solana has degraded performance

In 72efacf, RPC server - Figment Solana ($FIGMENT_SOLANA_RPC_URL) experienced degraded performance:

HTTP code: 200
Response time: 509 ms

Resolved: RPC server - Figment Solana performance has improved in d68f119.


Not Properly saving????

Error: Service Unavailable
Error: Service Unavailable
    at Request.<anonymous> (https://homebrewery.naturalcrit.com/homebrew/bundle.js:71824:19)
    at Request.Emitter.emit (https://homebrewery.naturalcrit.com/homebrew/bundle.js:1764:20)
    at XMLHttpRequest.xhr.onreadystatechange (https://homebrewery.naturalcrit.com/homebrew/bundle.js:72133:10)
{
  "status": 503,
  "method": "PUT",
  "url": "/api/update/uz46sv7vV4oy"
}

Check out the discussion at #1580 and see if that helps.  Going to close this as a duplicate for now, but let us know if the steps in #1580 don't resolve your issue and we can reopen this issue.

honestly i didnt do what you said, it just started working
thank you for the advice though!
it was a big scare to see my work wasn't being saved....


Windows app shows wrong start time with duration mode and continue

If user continues task from past day the start time is set to the same time as that of the past entry. Duration is correct but start and end time don't show correct values.
Full details:363875

This is really annoying and made go back to the web interface.


feat: new merge function

Which problem is this PR solving?

New merge function for merging configs, replacing dependency on lodash.merge
Moved from lodash only few small pieces - staying in separate file,
full unit tests

Looks good to me once the comment valentin made is resolved. Thanks for adding comprehensive tests.


Handled NaN exception in Length Calculator

Fixes Issue🛠
Closes #259
Description👨💻
Handled NaN exception in Length Calculator, if the user clicks on convert button without entering any numeric value in the input field, an alert message is displayed prompting the user to enter a valid number.
Type of change📄

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

How this has been tested✅
Tested on my local machine, looks and works as expected.
Checklist✅

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added demonstration in the form of GIF/video file
[x] I am an Open Source Contributor

Screenshots/GIF📷

Merged ✨ @SoumyadevSaha


Mp4/Mov file not uploading

HTTP Status 400: Bad Request, Response: {"request":"/1.1/media/upload.json","error":"media type unrecognized."}
I'm sending an .mov/.mp4 file. did twitter support mov/mp4?

This seems to be addressed with improved support in  #310. Closing this now.


GitHub workflow

Adding the Github workflow directory

I think we may want to see if it's possible to use the newer actions repo in build.yml instead of having everything directly in build here. This one is linked that way: https://github.com/adafruit/Adafruit_CircuitPython_Display_Text/blob/main/.github/workflows/build.yml
I'm not sure if there are any differences that will be needed due to circuitpython org instead of adafruit org, but ideally we want to re-use as much as we can.
having it in a seperate centralized location makes it easier to update the actions across all repos if/when the time comes.

@FoamyGuy Please take a look a #7 This solves the CI action, however it will fail, as the library needs some corrections to pass the test completely. So I propose the following:
We integrate the build.yml either manually or via PR even if the CI fails and then we could integrate PR #6 that will fix the library infrastructure problems. Let me know. Thanks :). Also I will close this one as #5 has the same intention and is cleaner. Thanks


fix: use APISIX master branch code to run e2e test

Please answer these questions before submitting a pull request

Why submit this pull request?

[ ] Bug fix

[ ] New feature provided

[ ] Improve performance

Related issues

Bugfix

Description

How to fix?

New feature or improvement

Describe the details and related test reports.

Codecov Report

Merging #9 (22b6d2d) into master (1a38fa6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #9   +/-   ##
=======================================
  Coverage   43.03%   43.03%
=======================================
  Files          18       18
  Lines        1271     1271
=======================================
  Hits          547      547
  Misses        632      632
  Partials       92       92

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1a38fa6...22b6d2d. Read the comment docs.


Postcode logic

JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

I assume this switch from AOL to service area won't affect the legacy search?

it shouldnt, its a different endpoint and the search still uses AOL, we just find it before.


Update proto for udf

protoc-gen-go updated and we need a new udf.pb.go file to match.
Need to figure out a simple way of locking the version of protoc-gen-go that we use. Should I just vendor it?

I didn't like where that was going... :(


Updated DEV guide with the new initialization api

Description
Companion PR for: https://github.com/opensearch-project/OpenSearch/pull/8029
Issues Resolved
Part of https://github.com/opensearch-project/opensearch-sdk-java/issues/782
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@kolchfa-aws not able to add you as a reviewer, so tagging here for a review. Thanks!

LGTM! Waiting to merge until the companion PR is in

Companion PR is in!


update go containers to also install protobuffer tools.

These containers need some refactoring. We should create a guest-go-toolchain image to have a single definition of the toolchain, and derive go{build,test.check} from the base image. That would also make it easier for us to update everything from bullseye->bookworm which is another thing that needs to happen.
/lgtm


Initial documentation and adjustments to README.md

Note: this pull request affects library files in geometric_kernels: some imports and docstrings were changed to fix documentation errors/warnings. Minor changes include adding stuff to .gitignore and changing the "author" field in setup.py to "The GeometricKernels contributors" (we will probably need to come up with a more appropriate email in the future as well).

I managed to install and see the docs. Overall looks good to me.
We'll have to make sure doc-strings are nice everywhere (rn some places have some weird formatting and/or typos). That could be done in a separate PR, I guees.
Also I had to install sphinx-autoapi manually to compile the doc.
Overall nice job!