Extracts into target file directory, not current directory

I put a target file in /tmp, and then in a subdirectory ran binwalk -e /tmp/targetfw
The exit status was 0, but there was nothing extracted.  Eventually I managed to work out that the extraction was alongside the original target file, and not the current directory.  (Note that tar, zip, cpio, 7z, etc all extract into the current directory hence the expectation.)
At the very least I suggest updating the documentation (man page and wiki page) to mention this.  It may also be worthwhile having a message that says how many files were extracted and where, although that is a little contrary to the unix philosophy of being silent on success.

Agreed; pushed patch to output all files to CWD.

Would it be possible to allow the user to modify the output directory, e.g. using an additional argument? I have a multithreaded application using the Binwalk API that concurrently extracts multiple firmware images each to a unique temporary directory, but this now fails since the current working directory is per-process and not per-thread.

There is now a --directory option that lets you specify a directory other than CWD.


StatusNotification info field

Hello, good morning!
How can I add the optional field "info" in StatusNotification.req when I execute ocpp_setConnectorPluggedInput_m??
Currently, with ocpp_setConnectorPluggedInput_m, I manage to transition the connector to Preparing correctly, but I also want the "info" to be sent in that Status.
I am implementing code in C.
Thank you very much in advance!

Hi @martamartz,
Unfortunately, it is not possible to fill the info field with the ConnectorPluggedInput. You may specify an error code and info if you set the ErrorDataInput (C++):
https://github.com/matth-x/MicroOcpp/blob/12d4868200d9675d98ff81b9c226e5deace64c12/src/MicroOcpp.h#L273
To add such custom functionality, it's necessary to go beyond the MicroOcpp_c.h facade and interact with the C++ modules. That's not too complex in C. Add two extra files "ocpp_helper.h" and "ocpp_helper.cpp" to your repository. ocpp_helper.cpp will contain the C++ code and interact with the internals of the OCPP lib. ocpp_helper.h contains C-style functions inside these linkage specifiers:
https://github.com/matth-x/MicroOcpp/blob/12d4868200d9675d98ff81b9c226e5deace64c12/src/MicroOcpp_c.h#L46-L48
https://github.com/matth-x/MicroOcpp/blob/12d4868200d9675d98ff81b9c226e5deace64c12/src/MicroOcpp_c.h#L188-L190
Then your C app can call the functions declared in ocpp_helper.h which will execute the C++ code in ocpp_helper.cpp (there are great tutorials out there for more details).
In ocpp_helper.cpp, you can register an ErrorCodeInput specifying the info field for an error StatusNotification message.
If it's not important that the info comes with the connector plugged StatusNotification, you may also send a custom StatusNotification message. Add a function like this:
void ocpp_statusNotification(const char *info) {
    auto context = MicroOcpp::getOcppContext();
    //create a StatusNotification object and send it via `context`
}

Creating a StatusNotification object looks like this:
https://github.com/matth-x/MicroOcpp/blob/12d4868200d9675d98ff81b9c226e5deace64c12/src/MicroOcpp/Model/Authorization/AuthorizationService.cpp#L179-L192
Instead of setting cpStatus for connector 0, you would have to pass the status of the current connector. Replace "LocalListConflict" with an ErrorData object.

Hello again,
I have managed to send a StatusNotification with the info field.
However, when doing it without ocpp_setConnectorPluggedInput, I think the library doesn't know that the EV is connected, and therefore, when I want to charge, a Start is not sent.
How could I solve this?

I would restore the old ocpp_setConnectorPluggedInput and send the custom StatusNotification messages on top of that. That adds a little redundancy but I would be surprised if it breaks the server.


stt,tts: add timeout functionality

introduces a new named argument to TTS, STT, and VAD: timeout: float. if set to 0, it will be ignored. if not, the abstract async __anext__() gets wrapped in a timeout.
STT.recognize is not iterable so its timeout is implemented at the plugin level.
defaults to 0 to preserve backwards compatibility.

There is some (http) clients that don't follow the timeout provided in the constructor (e.g google and azure)

There is some (http) clients that don't follow the timeout provided in the constructor (e.g google and azure)

azure SDK can't set a timeout, as far as i can tell

i think the issue with google STT failing is that it takes it more than 10 seconds to warm up. setting it to 30 seems to do the trick

For the STT, I don't think the timeout should be handled in the baseclass like we do for TTS.
The reason is that we don't know when the user stopped speaking. So if the user speaks for more than 10s and the STT doesn't support interim results. It is going to raise a TimeoutError
For the STT, I think the timeout handling is specific to each STT?
There is the timeout of the Connection (e.g Websocket). And the timeout waiting for the first transcript.
The latter is hard to correctly detect. This is actually what's happening for Google STT (bumping the timeout to 30s isn't the right solution here).

non-streaming STT seems to be fine, even with large frames. for streaming, you're right, we need to implement that on the plugin side as well. ws_connect(heartbeat: ...) works for Deepgram TTS, but both Azure and Google are accessed via SDKs, which as far as i can tell don't expose these heartbeat methods.

this should (🤞) be ready for final review now, while i figure out two remaining issues: the Azure timeouts, and the fact that a lot of scary (but safe!) RuntimeErrors appear when a transcription times out.

re-added STT timeouts:
non-streaming STTs simply time out with asyncio if they don't get the result in time.
for streaming STTs, there is a _timeout_exc attribute that is either None or TimeoutError, and is checked on every __anext__(). circumstances differ depending on implementation:

Deepgram uses aiohttp's heartbeat attribute for websockets. if the websocket receives WSMsgTypeError of type ServerTimeoutError, it sets _timeout_exc and breaks from _main_task
Azure starts a timeout on every first AudioFrame after a SpeechEvent and clears it every SpeechEvent
Google and StreamAdapter both just await the next SpeechEvent and time out accordingly

making sure a failed STT prompts "sorry, i didn't hear that" is the FallbackAdapter's job, and will be handled in that PR once this one is merged.
@livekit/agent-devs please review and nitpick


fix: demo now points to corrected files in meta-aws-demos

Issue #, if available:
Description of changes:
Correcting the paths used on the demo post-restructuring.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thank you for your contribution!


Rule PLR6301 ignore comment requires odd location

Method `construct_build_command` could be a function, class method, or static method

The following is the proper way to ignore PLR6301 when the function/method spans multiple lines:
def construct_build_command(
    self,  # noqa: PLR6301
    *,
    directory=None,
    targets=(),
    hooks_only=False,
    no_hooks=False,
    clean=False,
    clean_hooks_after=False,
    clean_only=False,
):

Should it not be the case that ignore comments be on the method?

Yeah this seems off. I think it's flagging the self, but we should probably move it to the method name.

Thanks!


chords can be compressed better + note on duration instead of note off

a huge amount of space is consumed if you have a lot of chords in a MIDI track. Each note in the chord will have velocity, note value, and delta time. Very often this is 6 note chords (4 chords RH, 2-3 in LH), for the whole piece.
The compressor unfortunately doesn't deal with it well, so we might need to intervene. Generate a dictionary of chords from midi data. Within +/- relative velocity, note offset, time offset, generate a dictionary of chord profiles. Instead of a note on, call it a chord on, where the note value / velocity / time are the base for the dictionary.
I would be curious to see an analysis of this on my pieces because i think it could save a lot of space.

along with chord dictionary, I think note durations in general can be probably better handled. Instead of this:

note on event

note value
velocity
time since last event

note off event

note value
time since last event

this can be shortened to:

note on event

note value
velocity
time since last event
duration

and now if duration is included with note ons, chord dictionary does not need duration info but just the note value.

some other alternative ideas than the "chord dictionary":

Each note can have a flag that allows you to add notes to the chord. though i feel like a simple quantization would have almost the same effect (because then note delta duration & delta time would be 0).

Ultimately the idea is to map musical patterns to patterns that the compression will pick up. More experiments to be done.

we made good ground with #96 and others; it's not likely that chord support can add much there. maybe someday if i really need to compress a lot more.


Scraping Tool Kit fixes

Made updates to use CONSTANTS.py to handle situations where the ingestion nodegroup name has invalid characters  for python function calls. ReadNodegroups.py was updated to correctly get the nodegroup name regardless of os.

Is this pull request still relevant?  It should either be merged or closed, not left to linger for a long time.


stopped working

worked for 2-3 days on edge and it suddenly stoped working on everything and theres no fix

same thing for me, even if I clear the cookies it doesn't work

Please update to https://github.com/besuper/TwitchNoSub/releases/tag/0.7.1


automatically exchange expired DO oauth tokens for fresh ones

Rather than triggering an avoidable new OAuth flow.
Looks like this is supported:
https://developers.digitalocean.com/documentation/oauth/#refresh-token-flow

Hm, looks like we're currently hitting the DO API's /authorize endpoint, which gives back an access_token with an expires_in but no refresh_token:
Got OAuth response: https://fmdppkkepalnkeommjadgbhiohihdhii.chromiumapp.org/#access_token=...&token_type=bearer&expires_in=2592000

I was confused for a sec because https://developers.digitalocean.com/documentation/oauth/#refresh-token-flow describes refresh_token as "The refresh_token that was received with the original access token", but then I realized there's another endpoint, /oauth/token, which we're not currently using and it looks like this is what we need to hit to get a refresh token: "In addition to other information, the response includes two important items: access_token and refresh_token." I guess they provide the access_token without the refresh_token in response to the /authorize request to offer applications that don't need a refresh_token a shortcut?

In any case, looks like it's just a matter of making a follow-up /oauth/token request to get the refresh token, which getOAuthFromStorage_() can then use to get a fresh token if it detects that the one we have stored has expired.

Hm, actually hitting /oauth/token is part of the web application flow, but we are using the client application flow. Emailed DO support asking them to clarify.

Closing as this is not a priority right now.


compose.lock

Hey there, when I try to update to the new version I get:
error: Your local changes to 'composer.lock' would be overwritten by merge.  Aborting.
I am actually logged off. What else can I do?
Thank you very much and keep up the great work!
Reiner

Probably because you have done a composer update instead of composer install. Just revert the file: git checkout composer.lock and check with git status what else you have modified...

thank you, this worked.


The repo is empty

Please fill the repo with code.

I'm working on transcribing everything from a Google Doc to pure Latex files. I'll make a post in r/math when this is finished.


Add jQuery to the kit

jQuery is extremely useful, especially for prototyping - I think it should be in the kit 'out of the box'

added in alphagov/govuk_prototype_kit#18


Want understanding correct server-side cache page

hi , usually I use nuxt generate project , but I have a frequently update project need deploy nuxt project self hosting ( with SSR ).
As I know we can set nuxt.config.js  cache as true to open cache
and in page component set name and serverCacheKey for component cache ..
ok ... but I in my case , I always have 3-4 sec TTFB ( server-side fetch data alway )
... In face , I check the source code , It really have cache for the date date ( no change when fresh )
ummm....  it seems like server-side return a cache data , but still block on async/await function...
why it now just return a cache data , and escape asyncData function ? ..
Am I do it correct ?
And if I fetch data in vuex serverInit , does it have cache ? Cloud I also get a long time TTFB ?
this is my code ... just fetch a fake 3 second delay function

thanks.
and you can try my test on this url
http://cache-test.dk.finpo.com.tw/
( note !! open this link need wait over than 3 seconds. )
( maybe this link can't browser few month later ... )

It looks like my misunderstand something ....
remote data not fetch again in client render ( I monitor chrome network )
so.... page loading just need 3 sec ( SSR + client ) not 3*2 sec .
but how can I cache data from server side ? I want reduce TTFB when second time load page...
( just throw a cache page -with remote data for SEOO ) and client fetch again ( loading....  and append data )

hi , It's me again ...
I have some tested about cache ...
I use nuxt/express create a project , like before for test TTFB issue .
I add a  package apicache , like it's name , it's a middle cache for all route
so I add to my server.js
...
const apicache = require('apicache')
let cache = apicache.middleware
app.use(cache('5 minutes'))
...

I execute yarn run dev
first time , I got 4 seconds TTFB , when I refresh , it down to 27ms
but .... the asyncData dose not call api again on client-side ...
( reasonable ) it's same without apicache ...
so , for client side re-fetch data .. I modify my code as following
index.vue
<script>
import axios from 'axios'

async function fetchData() {
  const { data } = await<EMAIL_ADDRESS>  return Object.assign(data, { date: Date.now() })
}

export default {
  name: 'home',
  data() {
    return { loading: false }
  },
  async asyncData () {
    // get a just 3 second delay api
    return await fetchData();
  },
  async beforeMount () {
    this.loading = true;
    const data = await fetchData();
    this.text = data.text;
    this.date = data.date;
    this.loading = false;
  }
}
</script>

when I refresh , I got 27ms TTFB , and 3 seconds loading and append new data .
voilà!
but ... if that page has no cached , that person will waiting 4 seconds TTFB and 3 seconds loading....
seems not very good ... ( if cache time is long enough , should a few people waiting so long ... )
I don't know is this a best practice ? or correct ? ....
If use SSR ( just fetch a few http request api data ) will create a long time TTFB every request ...
I don't know how to use SSR on demand .
@Atinux  If nuxt.js had server-side component cache , should nuxt.js need server-side data cache ?
but , as I know , cache have many choose , like memory , filesysem , keyvalue db ...etc
and many option ... TTL , memory size , file size , db connect ...
but .. if without this , are we really only accept long time TTFB ?
( I just have request 2-3 api data , my TTFB is 3s )....
herer is my express demo link . it cache 5 mins .
If no one access this page , you need 3 sec TTFB , and 3 sec Loaing .
( refresh just 25ms TTFB , and 3 sec loading ... )
http://express-test.dk.finpo.com.tw/

@ausir0726 Nuxt simply uses what Vue recommend for caching. You can have a look on the official Vue SSR Documentation for understand how caching works.

just share my resolve .
I install a varnish cache server front nuxt.js server , and a nginx server front varnish server .
and varnish cache nuxt.js render html about 15min - 1day ,  and nginx use e-tag cache .
so , in 15 mins , just one visitor need long time TTFB , other just only need about 25ms
if api data changed , I trigger varnish clear that page cache , and nginx will generate a new e-tag .
visitor will get a new fresh SSR page .
seems it a best solution for me . now my TTFB is reduce 1.7s- 2s to 46ms ( just e-tag check 20ms )


Add support to the Group struct for file_template_project_id

Currently, UpdateGroup allows for passing in the file_template_project_id attribute, but the Group struct doesn't include the attribute, so the GetGroup func doesn't return the value.
I'll go ahead and submit a PR to add the json attribute to the Group struct so that the value is returned appropriately from the GetGround func.

Submitted PR #1394 to resolve this issue.


afterStateUpdated unable to use $set to update DateTimePicker field, DateTimePicker is set to null

Package
filament/filament
Package Version
v3.0.0
Laravel Version
v10.0.0
Livewire Version
v3.0.0
PHP Version
PHP 8.3.0
Problem description
afterStateUpdated unable to use $set to update DateTimePicker field, DateTimePicker is set to null
Expected behavior
Able to use $set to update DateTimePicker field
Steps to reproduce
SpatieMediaLibraryFileUpload::make('photos')
->image()
->multiple()
->reorderable()
->reactive()
->afterStateUpdated(function (Set $set, $state) {
$set('paid_at', now()->addDay())
}),
Forms\Components\DateTimePicker::make('paid_at')
->default(now())
->required(),
Reproduction repository
https://github.com/cao-minh-duc/expense-tracker
Relevant log output
No response

Try now()->addDay()->toDateTimeString()


Do not sort by default when concatenating pandas data

Avoids very large futurewarning when concatenating pandas datasets.

maybe when running nosetests or ideally when building docs?

Unlikely to catch anything since the tests pin libraries to versions that are known to be supported.

Unlikely to catch anything since the tests pin libraries to versions that are known to be supported.

True but we might want to consider adding some tests that check against the latest version of everything...


New version: JannisX11.Blockbench version 4.9.2

Pull request has been created with WinGet Automation :rocket:
Microsoft Reviewers: Open in CodeFlow

@wingetbot run


Implement services loading from subfolders

Hi everyone.
I have issue when working with many services. I saw service loader in sails source and find that service loader doesn't support loading from sub folders.
loadServices: function (cb) {
      buildDictionary.optional({
        dirname     : sails.config.paths.services,
        filter      : /(.+)\.(js|coffee|litcoffee)$/,
        depth     : 1,
        caseSensitive : true
      }, cb);
    },

But when you have big codebase in project it became headache because too many files located under one directory. Some services can be grouped in one sub folder, some else in another sub folder. So will be great if sails supports loading services from subfolders.
What you think?

@sgress454 is working on a subapps hooks that loads API and config from node_modules or other directories. So, you have two different options: use this hook or override the default moduleloader

@ghaiklor Did you ever find a good answer on this?  I too would like to store services in subfolders

Sure, there it is: https://github.com/balderdashy/sails-hook-subapps

@irobayna I'm using this workaround :smiley:
// api/services/some/module.js
module.exports = {};

// api/services/SomeService.js
var subModule = require('some/module.js');

@ghaiklor thanks for the feedback, interesting solution.
I am not sure I like having to create the fake service as we are going to have lots of services.  And could be somewhat of a PIA to do the double typing.
Check out this, just as an FYI... just ran a quick test and it this seems to work well
https://github.com/balderdashy/sails/issues/2181 (check my comment)

@loicsaintroch Thanks!, I don't want to load a sub app but rather divide my services up as we will have potentially hundreds and we thought it would be a cleaner approach.

@irobayna This is not fake service. Let's say you have different ciphers and you need work with them. Here the solution how to split it to subfolders.
// api/services/cipher/bcrypt.js
module.exports = {
    hash: function(data) {}
};

Then lets add whirlpool cipher:
// api/services/cipher/whirlpool.js
module.exports = {
    hash: function(data) {}
};

So each module is split and located under sub-folders. It can be whatever you want: class, function, object, just make sure that you have module.exports.
And then create in api/services file named as you want, for instance Ciphers.
// api/services/Ciphers.js
module.exports = {
    bcrypt: require('./cipher/bcrypt'),
    whirlpool: require('./cipher/whirlpool')
};

And then you can use it like this Ciphers.bcrypt,hash('password'). I hope you got the idea :smiley:
I'm using services as Factory classes which create appropriate instance from sub folder. Here example from my yeoman generator - https://github.com/ghaiklor/generator-sails-rest-api/tree/dev/generators/app/templates/api/services

@ghaiklor Thanks!! makes way more sense now.  Pretty cool solution!

Couple of points here:

The reason that services are explicitly set to depth: 1 is that people often have a lib or helper folder underneath api/services which they use to store support files that shouldn't be globalized
Remember that the globalizing of services (and models) is purely for convenience--there's nothing wrong with require('../services/cipher/whirlpool.js') in your controller code.

@ghaiklor you have a nice, elegant solution to the issue there that allows for easy modularization without hacking the moduleloader--good job!

@sgress454 Thanks :smiley:  but I'm still thinking about creating Mediator which will register\unregister services. Because exposing all files from api/services to global can be dangerous. So I want to create one global variable like Services which have register() method. And store all services there without exposing them to global.

For those who would like this feature anyway, just put the following in api/hooks/serviceLoader.coffee
(Use CoffeeScript website to convert it to JS if needed, but it should work as it is)
It will expose the api/services/DataServices/Config.coffee file as:

sails.services.dataservices.config

DataServices.Config if sails.config.globals.services is enabled
buildDictionary = require 'sails-build-dictionary'
class ServiceLoader
constructor: (sails)->
  @sails = sails

initialize: (cb)->
  @sails.log.info 'Service Initialize'
  @cb = cb
  @loadServices()

loadServices: ->
  buildDictionary.optional {
    dirname     : @sails.config.paths.services
    filter      : /(.+)\.(js|coffee|litcoffee)$/
    caseSensitive : true
    flattenDirectories: true
    keepDirectoryPath: true
  }, @bindToSails

bindToSails: (err, modules)=>
  if err
    @sails.log.error 'Error occurred loading modules ::'
    @sails.log.error err
    return @cb()

  @sails.log.verbose 'Loading nested app services...'

  _.each modules, (module)=>
    # Root Services are already loaded by `moduleloader`
    return if -1 is module.identity.indexOf '/'
    module.sails = @sails
    _.bindAll(module)

    @loadModule module

  @cb()

loadModule: (module)->
  iParts = module.identity.split('/')
  gParts = module.globalId.split('/')

  sRoot = @sails.services
  gRoot = global

  while iParts[1]
    iPart = iParts.shift()

    sRoot[iPart] = {} if not sRoot[iPart]
    sRoot = sRoot[iPart] or (sRoot[iPart] = {})

    if @sails.config.globals.services
      gPart = gParts.shift()
      gRoot = gRoot[gPart] or (gRoot[gPart] = {})

  sRoot[iParts[0]] = module
  gRoot[gParts[0]] = module if @sails.config.globals.services

  module.identity = module.identity.replace /\//, '.'
  module.globalId = module.globalId.replace /\//, '.'

module.exports = (sails)->
return initialize: (cb)->
sails.after 'hook:moduleloader:loaded', ->
(new ServiceLoader(sails)).initialize(cb)

@Tronix117 thanks for posting your solution!  This is precisely the kind of stuff the hook system was designed to support.  As much as possible, we're hoping to keep core out of your way and expose the APIs you need to customize Sails in pretty much any way you want.

@ghaiklor does this work to you in controllers? I cannot require my service module in my controller. I've tried to use
../service/path-to-my-service/MyService.js
../../../(as many times as folders till meet api root)/service/path-to-my-service/MyService.js
path-to-my-service/MyService.js
and none of them simply work


Wrong timespan in host detail daily chart

When there is only one day of data (one daily rollup in db), seems like there is "by one error" somewhere. Most likely the dates are being substracted, which leads to this
where_clause: ["resource_type = ? and resource_id = ? and timestamp >= ? and timestamp <= ? and capture_interval_name = ?", "Host", 12, 2015-01-23 00:00:00 UTC, 2015-01-22 23:00:00 UTC, "daily"]
so from date is bigger than to date, which will always return empty dataset and chart in the detail page is empty.
When I have more daily rollups in database I can see the data in chart.

Where is this query being generated?  Is this a backend thing during collection, or a frontend thing on UI display?  I think the UI intentionally doesn't show data until at least 1 day has passed...maybe this is how they do it (which would be weird, I admit)?

Yes, (1 day is passed) == (you have daily rollup in your db) , right? So I believe it should show the data.
It is frontend thing during display. This is generating by the reporting lib that is building and rendering the chart (I forgot it's name), I haven't investigate where exactly is this generated.

@miq-bot move-issue manageiq-ui-classic


Add more specs for YAML::Any#[] and #[]?

This patch just adds some specs for Any#[] and Any#[]? which test with all YAML types as keys/indices.
Note: This just describes the current behaviour which has some shady edges. I'd like to merge this first and then work on several individual enhancements.

The purpose of these specs are not super obvious to me.  it seems like each test case is testing multiple edge cases and the naming is fairly generic.  I think breaking the test cases up might help with legibility.


skchem package for synergy maps

Dear synergy maps developers,
I saw the code is using skchem python package. How to install that?
Thanks,
Jing

Hi Jing,
skchem is an experimental package written by me looking to make rdkit more straightforward to use with pandas and the rest of the scientific python stack.  It should be installable using
pip install scikit-chem
Specifically, this package was tested with v0.0.1 release - the skchem API is definitely subject to change, so if it stops working after an update, try pip install scikit-chem==0.0.1.  I hope to keep this package up to date with the API though.
The source for scikit-chem is available here.
Please let me know if it doesn't work!

Could I ask about what dev tools you use for this app? I saw D3, JQuery and AngularJS. I am working on a project with D3. But, I didn't use MVC pattern. So, my current code is hard to maintain. Do you have any suggestion in terms of development?

My first iteration was the same - VERY hard to maintain and extend.  For this iteration, I used Angular 1 to modularize the app into different web components, which I think I have managed, at least to a certain extent - I feel this is the best way to build an easily maintainable and extendable app.  That said, this attempt is still quite messy as I was new to all the frameworks when I started, so I am planning on a rewrite for the next version.  Also, Angular 2 is coming soon, which seems a more modern way to develop modular apps.  I would recommend looking into a web component library (such as Angular 1 or 2, Aurelia or React) to keep the code separated.

Thanks for the suggestion! I am looking at Angular 2. Yes, with growing of functionality, the app becomes too complex to maintain. And, my initial architecture design didn't really anticipate the complexity of current situation. Do you have any response speed problem during your development? I saw the search bar, which might be slow for large data set.

Do you use Yeoman also?

Hi, sorry I have just revisited this thread after a VERY long time (I was replying in the gap between two lectures before, so must have missed your previous reply as the next lecture started).  Thought I would reply anyway, then close it, as I am considering starting version 3 in the near future.
I think you can filter the results in javascript before drawing in the search bar, which would hopefully minimise performance hits.
I did use yeoman, although I'm not so convinced it is a necessity any more, although can be very nice if you find a good generator, or extend it a bit.


Correcting testProjects parameter and syntax

Related Issue
Fixes #47
Checklist

[X] Has related GitHub Issue 💥
[X] Tested it
[X] Read the PR collaboration guide 👓 Collaboration Guide

Changes proposed in this pull request:

Changed parameter name (is correct in YAML)
Removed duplicated braces

Thank you so much, @mkennten!


pure-component name is potentially misleading

The pure-component codemod is concerned with stateless function components, not PureComponents. Does this mean the name is potentially misleading?
I have noticed SFCs referred to as "pure (function) components" in a few other places. It would be good if the terminology was used correctly/consistently.
Apologies if I am mislead here!

I agree it's misleading, but we'll keep this around for historical reasons I think.


Join changes

A problem arose with multiprocessing branch of the join producing invalid results. The problem is that mapping cannot be multiprocessed/run on fixed memory. Left table slice depends on the entire Right table indices additionally Left table slices depend on indices from all previous slices. Therefore this part was moved to be single processed.
Best we can do is reduce the memory footprint required by index dictionaries by either using hash of value as key instead of value itself or outright moving this to nim to reduce the object footprint.
Additionally, multiprocessing and singleprocessing join branches have been merged into one so that only a single algorithm needs to be maintained.

A cryptographic hash should be a safe choice, but moving to nim will surely be faster.

Codecov Report
Attention: Patch coverage is 92.10526% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 82.25%. Comparing base (03b7e72) to head (bf7c66c).

Files
Patch %
Lines

tablite/joins.py
92.30%
2 Missing :warning:

tablite/mp_utils.py
90.90%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #138      +/-   ##
==========================================
- Coverage   82.84%   82.25%   -0.60%
==========================================
  Files          27       27
  Lines        4220     4113     -107
==========================================
- Hits         3496     3383     -113
- Misses        724      730       +6

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


New specialist: Allin Clinic

I would like to add an entry to the list of specialists for an organisation I am aware of.  The organisation not yet been informed about this process.
(text below this line comes from the form you just filled out - please don't edit it here)

Entry data
{
  "name": "Allin Clinic",
  "description": "Providing care to Edmonton since 1946",
  "url": "https://allinclinic.ca/",
  "admin_contact": "",
  "specialist_type": "physician",
  "referral_types": [
    "direct"
  ],
  "registration_required": false,
  "appointment_types": [
    "in-person"
  ],
  "booking_required": true,
  "booking_url": "https://patient.medeohealth.com/booking/the-allin-clinic/",
  "booking_tel": "",
  "booking_fax": "",
  "booking_other": "",
  "before_first": "",
  "between_appointments": "",
  "outcomes": [
    "diagnose",
    "treat",
    "refer"
  ],
  "outcome_other": "",
  "procedure_type": "researched",
  "locations": [
    {
      "name": "The Allin Clinic",
      "address": "10155 120 Street\n2nd floor\nEdmonton, Alberta T5K 2A2",
      "gps": [
        "53.54277665",
        "-113.52850984285715"
      ],
      "tel": "(780) 482-7551",
      "fax": "(780) 488-2056"
    }
  ],
  "forms": [
    {
      "sharing_status": "found online",
      "instructions_to_find": "1. go to https://allinclinic.ca/documents-brochures/\n2. click on \"Two Week Sleep Diary Adult\"",
      "name": "Two Week Sleep Diary Adult",
      "url": "https://allinclinic.ca/wp-content/uploads/2021/03/Two-Week-Sleep-Diary-Adult.pdf",
      "use_before_first": "maybe",
      "use_between_appointments": "maybe"
    }
  ],
  "reports": []
}

Merging.


Flexi-net: Prep for mainnet with a few additional tweaks

Three things here:

Automatic mainnet config when web3 is set to mainnet.
Loud warning not to use an exchange for funding.
Proper surfacing of the revert reason in cases where a transaction fails
with a clear contract-side reason.

I was going to hold this as a draft until we finalized a rough design
for the exchange warning, but it'll be so easy to make changes in a
follow-up PR that I'll declare this ready for review.
See #297.

(Rebasing this now, also to ensure everything is formatted all prim and proper like :grin:)

Ok, should be good here.


fix reference price not converting base/quote asset in kind

The purpose of the reference_{base,quote}_price field is to simply show the amount {base,quote}_price converted against a well known price feed.
Take into consideration most of the time it will happen the base asset has no direct exchange rate somewhere else, so it must be converted to quote price first and calculate proportionally.

https://github.com/tdex-network/tdex-analytics/issues/24#issuecomment-1100198872


[IMPROVEMENT] Add a label and selector for webhooks to longhorn-manager pod manifest.

Is your improvement request related to a feature? Please describe (👍 if you like this request)
This came up in a discussion of the testing for #6205 where sometimes changes requested for fast failover, such as modifying the volume attachment, would time out because the admission webhook that was asked to validate the change may have been on the node that was failed but is not yet marked as "not ready."  In that case, the webhook request times out and will do so until the dead node is removed from the service endpoint slice by Kubernetes.
Describe the solution you'd like
@PhanLe1010 suggested this change, which adds a label to longhorn-manager pod for each webhook,
  longhorn.io/component: admission-webhook
  longhorn.io/component: conversion-webhook

and a selector on that label in the respective services.
If a node is suspected dead, the label can be removed by another node, and the dead node's IP will be removed from the endpoint slice.  When the node returns, it can add the label back to its own longhorn-manager pod's manifest when it is ready for the webhook to become active.
Although this necessary for reliable fast failover, it can also be used to control when the pod is considered ready, since the readiness probe uses the webhook to answer for the pod.
Describe alternatives you've considered

Additional context

Although this necessary for reliable fast failover, it can also be used to control when the pod is considered ready, since the readiness probe uses the webhook to answer for the pod.

Could you give a bit more details about this point. Now thinking about it, I am not sure how we can achieve this readiness probe effect

Could you give a bit more details about this point. Now thinking about it, I am not sure how we can achieve this readiness probe effect

IIRC, we weren't discussing this in conjunction with the readiness probe per se. I thought the idea was:

The readiness probe can pass as soon as the conversion webhook is up.
The admission webhook may not be up at that time.
We don't want a pod with only the conversion webhook ready to receive admission webhook requests. They will fail.
The pod can label itself when it is ready for either type of traffic (individually), so each appropriate service will only direct traffic to pods ready for that type of traffic.

When the node returns, it can add the label back to its own longhorn-manager pod's manifest when it is ready for the webhook to become active.

Could you give more details about the design and implementation?

Which controller is responsible for removing and adding the labels?
How to check if a node is dead?

@james-munson the milestone was missed. If working on it, need to ensure the milestone is set as well.

Is your improvement request related to a feature? Please describe (👍 if you like this request)
This came up in a discussion of the testing for #6205 where sometimes changes requested for fast failover, such as modifying the volume attachment, would time out because the admission webhook that was asked to validate the change may have been on the node that was failed but is not yet marked as "not ready." In that case, the webhook request times out and will do so until the dead node is removed from the service endpoint slice by Kubernetes.

The admission webhook is based on the service, and each Longhorn manager pod runs with the webhook. If one is unable to process the request, then the request should be handled by the others. Why does it get stuck until the dead node is removed? Or anything I missed?

The admission webhook is based on the service, and each Longhorn manager pod runs with the webhook. If one is unable to process the request, then the request should be handled by the others. Why does it get stuck until the dead node is removed? Or anything I missed?

Once Kubernetes realizes the node a longhorn-manager pod is running on is not ready, it no longer directs traffic to the associated endpoint (regardless of the pod status). For example, in my cluster, with a node down, I see:
# Pod status
longhorn-manager-nlm8h   1/1     Running   4 (4d2h ago)   6d18h

# Nodes status
eweber-v126-worker-9c1451b4-kgxdq   NotReady   worker                      176d   v1.28.9+k3s1

# Part of EndpointSlice status
- addresses:
  - <IP_ADDRESS>
  conditions:
    ready: false
    serving: false
    terminating: false
  nodeName: eweber-v126-worker-9c1451b4-kgxdq
  targetRef:
    kind: Pod
    name: longhorn-manager-nlm8h
    namespace: longhorn-system
    uid: 4333ddfb-4b16-4f8b-a284-771bff29cab9

So the node is not ready and traffic is not routed to the pod (which is supposedly running, but really Kubernetes just doesn't know its situation since kubelet is down).
@james-munson has the logs, but we saw:

Traffic is still routed to the pod on the down node until the node is NotReady.
For every API request involving a Longhorn object, there is a API server -> conversion webhook request and an API server -> admission webhook request.
Each request has a 10 second timeout.
The requests are routed to each backing pod (including the down one) randomly (and/or in round robin style).

So, in a three node cluster with one node down node, a single request to the API server has:

A 66.6% * 66.6% = 44.4% chance of reaching a functional pod on the first try.
A 33.3% chance of reaching a down pod for the conversion webhook and stalling for 10 seconds before failing.
A 66.6% * 33.3% = 22.2% chance of reaching a functional pod for the conversion webhook but a down pod for the admission webhook and stalling for 10 seconds before failing.

Now cumulatively:

In total, that's a 55.5% chance of AT LEAST a 10 second delay (and a 55.5% * 44.4% = 30.8% chance of ONLY a 10 second delay).
Then, there's a 55.5% * 55.5% = 30.8% chance of AT LEAST a 20 second delay (and a 55.5% * 44.4% = 24.6% chance of ONLY a 20 second delay).

Wrapping it up, that's a:

44.4% chance of no delay
24.6% chance of a 10 second delay
13.7% chance of a 20 second delay
7.6% chance of a 30 second delay
4.2% chance of a 40 second delay
5.3% chance of an even longer delay

If multiple requests are required for an action to complete (e.g. related to two different resources), the chances of getting stuck increase.
TLDR: You are right that there are other pods to service the webhook requests, but we may still be delayed for a really long time trying to get through to a working one. If it takes longer than ~40 seconds to do so, then @james-munson's fast failover work becomes relatively meaningless.

I was thinking of another idea @james-munson and @PhanLe1010. I can't remember if I said it during the workshop or not.
In the fast failover case, we could choose to delete the longhorn-manager pod on the node we suspect is down instead of using this label mechanism. This should also stop traffic from routing to the pod (which will be terminating).
On the one hand, it is probably MUCH less disruptive than deleting the instance-manager pod (or otherwise considering all engines to be crashed) in the case that the node is not actually down (false positive).

Thank you @ejweber for the detailed explanation of the issue.  That hits the nail on the head.
We did discuss the possibility of simply deleting the longhorn-manager pod on the suspected node.  If the suspicion is false and the node is actually up,  a new pod is created within seconds.  I'm not sure that there will be resource changes, since those also depend (I believe) on the node's ready state, not the existence of a pod.  Those resources owned by the node will go un-synced for a few seconds, but no other node would take responsibility.
Simple as that solution might be, we did hesitate to go that far, and the label/selector solution was attractigve because it addresses #8612 neatly.

As @ejweber also pointed out, if the labels are added dynamically, they should not be in the manifest yaml.  Only the selectors should be.  There will need to be a separate change in longhorn-manager to add the labels at startup, which should go here in the daemon startManager function https://github.com/longhorn/longhorn-manager/blob/1c19bfbd35d8fd59dba136cfc12a879c91b68f7c/app/daemon.go#L162 between StartWebhook and CheckWebhookServiceAvailability for the conversion webhook, and similarly for the admission webhook.
That should be sufficient for this ticket and for #8612.  For HA, it is necessary to know that the node is probably dead, which will use the Delinquent condition introduced in #6205.  It will have an additional change to remove the label when the condition is set to true.  If the node is not actually dead, the labels can be restored at the same time the condition is cleared, in the node_handler's sync code.  But that additional modification will be done in the other feature branch after this change is pulled in.

Lot of good statistics at https://github.com/longhorn/longhorn/issues/8803#issuecomment-2197297624 @ejweber 🚀
:D

I was thinking of another idea @james-munson and @PhanLe1010. I can't remember if I said it during the workshop or not.
In the fast failover case, we could choose to delete the longhorn-manager pod on the node we suspect is down instead of using this label mechanism. This should also stop traffic from routing to the pod (which will be terminating).
On the one hand, it is probably MUCH less disruptive than deleting the instance-manager pod (or otherwise considering all engines to be crashed) in the case that the node is not actually down (false positive).

I remembered we discussed this in the initial meeting long time ago? Yeah, the concern is the ownership transfer storm. And like @james-munson mentioned, a new Longhorn manager pod might be recreated quickly and prevent the RWX volume from detaching from that node? Though I agree that it will be useful to give this a POC if time allows, WDYT @james-munson ?

Could you explain a bit why 55.5% * 44.4% = 24.6% chance of ONLY a 10 second delay ?

Yeah, I had to calculate this all out a few times before coming to results I was confident in.

Every time we make an attempt to update a CR, there is a 44.4% chance of failure and a 55.5% chance of success.
There is a 55.5% chance of a failure on the first attempt of a CR update.
GIVEN that this occurred (i.e. GIVEN the 55.5% "path"), there is a 44.4% chance of success on the next attempt. This combination of events (55.5% * 44.4%) results in ONLY a ten second delay (caused by the failure on the first attempt). Otherwise, a failure occurs on the second attempt, leading to a further delay.

Here is a visual representation. The bolded probabilities are the "final" probability for a particular delay. There is still a 5.3% chance of a longer delay (so they don't add up to 100%).

🚀 That is a great statistic calculation! Many thanks!

@james-munson Please update the status of the ticket. Thank you.

Verified on master-head 20240726

longhorn master-head https://github.com/longhorn/longhorn/commit/d5e8a44104f5e03c310870b47da7c8ab55f671b3

Verified on v1.7.0-rc2 20240726

longhorn v1.7.0-rc2 https://github.com/longhorn/longhorn/commit/03d5faee809d984a71a17c04da863d571df009bb

The test steps
https://github.com/longhorn/longhorn/issues/8803#issuecomment-2194730868

List Longhorn-mamanger IP : Use kubectl get pod -n longhorn-system -owide |grep longhorn-manager to list all Longhorn-mamanger IPs in the longhorn-system namespace.

Describe each service to check selectors

kubectl describe svc longhorn-admission-webhook -n longhorn-system |grep Selector
kubectl describe svc longhorn-conversion-webhook -n longhorn-system |grep Selector
kubectl describe svc longhorn-recovery-backend -n longhorn-system |grep Selector

Describe each endpoint to check IP addresses

kubectl describe endpoints longhorn-admission-webhook -n longhorn-system |grep Addresses
kubectl describe endpoints longhorn-conversion-webhook -n longhorn-system |grep Addresses
kubectl describe endpoints longhorn-recovery-backend -n longhorn-system |grep Addresses

Result Passed
The test passed under the following scenarios:

Fresh install of v1.7.0-rc2
Fresh install of master-head
Upgrade from v1.6.2 to v1.7.0-rc2


Do patch instead of update

We are hitting a conformance test bug:
=== RUN   TestNetworkPolicyV2Conformance/AdminNetworkPolicyEgressNamedPort#01/Should_support_an_'allow-egress'_policy_for_named_port
2024-04-08T00:12:49.3743969Z     admin-network-policy-extended-egress-rules.go:78:
2024-04-08T00:12:49.3746768Z         	Error Trace:	/home/runner/go/pkg/mod/sigs.k8s.io/network-policy-api@v0.1.3-0.20240311165859-d48faeeb0e02/conformance/tests/admin-network-policy-extended-egress-rules.go:78
2024-04-08T00:12:49.3748756Z         	Error:      	Received unexpected error:
2024-04-08T00:12:49.3752415Z         	            	Operation cannot be fulfilled on adminnetworkpolicies.policy.networking.k8s.io "egress-tcp": the object has been modified; please apply your changes to the latest version and try again
2024-04-08T00:12:49.3756029Z         	Test:       	TestNetworkPolicyV2Conformance/AdminNetworkPolicyEgressNamedPort#01/Should_support_an_'allow-egress'_policy_for_named_port
2024-04-08T00:12:49.3757297Z         	Messages:   	unable to update the admin network policy

that happens because resource version changes for the resource, let's use patch in our conformance tests instead of updates.

/area conformance

/kind bug


Fix create card animation wonkiness

Animation makes the "+" card and the input card both show during the transition
Also, the rui-enter has apparently stopped working

RWARRR! Thanks for posting, @jdl031. Ich Bin RedoxBot-- nice to meet you!
It has been 60 days since there have been any updates or new comments on this page.       If this issue has not been resolved and needs to be re-opened, please take a minute to re-open it. Report problems with the bot to @nwhatt


after the sampLayer,there is a full connection named soft-max,i can't find the implementation

我也没找到全连接层在哪里？？？


It's Not Just Linux, Dammit

Please stop ignoring BSD, Solaris, etc. users ;-)

Up - vote

:sparkles: :cake: :sparkles:


Add Polish translation

Please, clean your PR from 3rd party commits and i'll merge it.

I new in sending PR
so create new PR or what ?

@radepal
git checkout develop
git remote add mink git://github.com/Behat/Mink.git
git fetch
git rebase mink/develop
git push origin develop --force


add simple demo ppl test with wikitext2

This is a demo code using ppl to test the performance of AutoGPTQ.
opt - 125m
RTN baseline 37.27 ppl
GPTQ for llama 29.21 ppl
AutoGPTQ 29.87 ppl
Some performance degradation is observed, but it seems to be a minor error.

Yeah, I can also confirm that there is a small gap between AutoGPTQ and GPTQ-for-LLaMa by running this example.
I'm not quite sure if it's because AutoGPTQ's  logic used in model.quant() function and how attention_mask been processed is slightly different with GPTQ-for-LLaMa.
This finding is important, maybe there's room for improvement here.
I think this pr can be merged.

I have now confirmed that this issue is caused by a difference in 2 places.

use symmetric quantization
use true sequential (If you don't want to use it, you can implement it like this)

    inside_layer_modules = [
        ["self_attn.k_proj", "self_attn.v_proj", "self_attn.q_proj",
         "self_attn.out_proj",
         "fc1",
         "fc2"]
    ]

I actually experimented with this and got 132 ppl. And for reference, I saved the opt model in GPTQ_for_LLaMA and then reloaded it and evaluated it and got a ppl of 132. This means you can make GPTQ for LLaMA and autoGPTQ work identically with two simple changes.


Add tests for log handler

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.07%. Comparing base (46a07ef) to head (805b145).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1219      +/-   ##
==========================================
+ Coverage   95.03%   95.07%   +0.03%
==========================================
  Files         105      105
  Lines       12587    12587
==========================================
+ Hits        11962    11967       +5
+ Misses        475      471       -4
+ Partials      150      149       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fix: endpoint body type inference

Endpoint's body type inference is actually broken for express.
I've added a test, but there's an error with old ones as a snapshot update is probably needed.
By the way, happy new year 🌈

happy new year greenman 🎄 🎉
you stand correct, I updated the snapshot and tests run fine.
My only doubt is, should we mark this "breaking" before merging on master thus releasing the alpha?

happy new year greenman 🎄 🎉
you stand correct, I updated the snapshot and tests run fine.
My only doubt is, should we mark this "breaking" before merging on master thus releasing the alpha?

Actually I didn't want to update the snapshot cause undefined is the right value to show, but the generic type definition for body was wrong.
We may also need to put some debug in the code for the v2 :)

Actually I didn't want to update the snapshot cause undefined is the right value to show, but the generic type definition for body was wrong.
We may also need to put some debug in the code for the v2 :)

Actually I didn't want to update the snapshot cause undefined is the right value to show, but the generic type definition for body was wrong.

ops I didn't get it :) apparently checking first the undefined case helps the compiler infer the correct type (no idea why 🤷♂)

We may also need to put some debug in the code for the v2 :)

Do you mean internal logging (not exposed when published) or as a feature for the user?
(p.s. I am planning a "CQRS flavored" version of ts-endpoint that also take care of caching/invalidation [a sort of mash between ts-endpoint and avenger], I am trying to come up with the API I'd like to have here https://github.com/fes300/cq-ts/blob/master/docs/ts-cq/simple-guide.md)

Actually I didn't want to update the snapshot cause undefined is the right value to show, but the generic type definition for body was wrong.

ops I didn't get it :) apparently checking first the undefined case helps the compiler infer the correct type (no idea why 🤷♂)

We may also need to put some debug in the code for the v2 :)

Do you mean internal logging (not exposed when published) or as a feature for the user?
(p.s. I am planning a "CQRS flavored" version of ts-endpoint that also take care of caching/invalidation [a sort of mash between ts-endpoint and avenger], I am trying to come up with the API I'd like to have here https://github.com/fes300/cq-ts/blob/master/docs/ts-cq/simple-guide.md)

For the debug we can use debug which is widely used.
and use the name @ts-endpoint:$submodule.

https://github.com/fes300/cq-ts/blob/master/docs/cq-ts/simple-guide.md

This is really interesting and I'm developing something similar in the project I'm working on.
Just one question, why another repo and not adding the package to this one?

For the debug we can use debug which is widely used.
and use the name @ts-endpoint:$submodule.

https://github.com/fes300/cq-ts/blob/master/docs/cq-ts/simple-guide.md

This is really interesting and I'm developing something similar in the project I'm working on.
Just one question, why another repo and not adding the package to this one?

This is really interesting and I'm developing something similar in the project I'm working on.
Just one question, why another repo and not adding the package to this one?

just because I don't see any overlap with what we have in ts-endpoint (maybe just a couple of codecs that could be helpful but I'd prefer to keep it separated at this point).
Do you see any reason why they should be in the same repo?

This is really interesting and I'm developing something similar in the project I'm working on.
Just one question, why another repo and not adding the package to this one?

just because I don't see any overlap with what we have in ts-endpoint (maybe just a couple of codecs that could be helpful but I'd prefer to keep it separated at this point).
Do you see any reason why they should be in the same repo?

I see a lot of overlap between these packages as you're basically building
an entire ecosystem to exchange data starting from the endpoint definition.
You can choose an exotic name for your project, but I would keep everything
in a single repo cause the packages are highly dependant one from the other
:)
On Thu, 7 Jan 2021 at 10:01, Federico Sordillo<EMAIL_ADDRESS>wrote:

This is really interesting and I'm developing something similar in the
project I'm working on.
Just one question, why another repo and not adding the package to this one?
just because I don't see any overlap with what we have in ts-endpoint
(maybe just a couple of codecs that could be helpful but I'd prefer to keep
it separated at this point).
Do you see any reason why they should be in the same repo?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/fes300/ts-endpoint/pull/59#issuecomment-755981616,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOA3Z26LLWXQ23O7A5JARDSYVZ7TANCNFSM4VQSU6UA
.

I see a lot of overlap between these packages as you're basically building
an entire ecosystem to exchange data starting from the endpoint definition.
You can choose an exotic name for your project, but I would keep everything
in a single repo cause the packages are highly dependant one from the other
:)
On Thu, 7 Jan 2021 at 10:01, Federico Sordillo<EMAIL_ADDRESS>wrote:

This is really interesting and I'm developing something similar in the
project I'm working on.
Just one question, why another repo and not adding the package to this one?
just because I don't see any overlap with what we have in ts-endpoint
(maybe just a couple of codecs that could be helpful but I'd prefer to keep
it separated at this point).
Do you see any reason why they should be in the same repo?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/fes300/ts-endpoint/pull/59#issuecomment-755981616,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOA3Z26LLWXQ23O7A5JARDSYVZ7TANCNFSM4VQSU6UA
.

they have an overlap in use but not in code, they are basically two alternatives to solve the same problem.
Could you point me to where you see interdependencies? (because I actually see none :D)

You can choose an exotic name for your project
not a big fan of cq-ts, what do you think of cqrs-ts? Looks a little more familiar

they have an overlap in use but not in code, they are basically two alternatives to solve the same problem.
Could you point me to where you see interdependencies? (because I actually see none :D)

You can choose an exotic name for your project
not a big fan of cq-ts, what do you think of cqrs-ts? Looks a little more familiar

You duplicated the Endpoint definition in this new repo, that's why you
don't have dependencies :)
cqrs-ts is not an "exotic" name, but more a boring-legacy name: what do
you think about sharedpoint-ts?
endpoint -> startpoint (cause in this case we "start" from the endpoint
definition) -> sharedpoint (one endpoint for all)
On Thu, 7 Jan 2021 at 11:30, Federico Sordillo<EMAIL_ADDRESS>wrote:

they have an overlap in use but not in code, they are basically two
alternatives to solve the same problem.
Could you point me to where you see interdependencies? (because I actually
see none :D)
You can choose an exotic name for your project
not a big fan of cq-ts, what do you think of cqrs-ts? Looks a little more
familiar
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/fes300/ts-endpoint/pull/59#issuecomment-756030197,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOA3Z6TGWVV6UWSXUPIEJDSYWEKRANCNFSM4VQSU6UA
.

You duplicated the Endpoint definition in this new repo, that's why you
don't have dependencies :)
cqrs-ts is not an "exotic" name, but more a boring-legacy name: what do
you think about sharedpoint-ts?
endpoint -> startpoint (cause in this case we "start" from the endpoint
definition) -> sharedpoint (one endpoint for all)
On Thu, 7 Jan 2021 at 11:30, Federico Sordillo<EMAIL_ADDRESS>wrote:

they have an overlap in use but not in code, they are basically two
alternatives to solve the same problem.
Could you point me to where you see interdependencies? (because I actually
see none :D)
You can choose an exotic name for your project
not a big fan of cq-ts, what do you think of cqrs-ts? Looks a little more
familiar
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/fes300/ts-endpoint/pull/59#issuecomment-756030197,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOA3Z6TGWVV6UWSXUPIEJDSYWEKRANCNFSM4VQSU6UA
.

You duplicated the Endpoint definition in this new repo, that's why you
don't have dependencies :)

hoo I see what you mean now, that's just a leftover there is nothing implemented yet (I just published the repo so that I could let you see the readme I was working about :D), when things will be finished there will be no Endopoint anywhere, just Commands and Queries 💣

cqrs-ts is not an "exotic" name, but more a boring-legacy name: what do
you think about sharedpoint-ts?
endpoint -> startpoint (cause in this case we "start" from the endpoint
definition) -> sharedpoint (one endpoint for all)

not bad you got a point, the idea is very cool but I think sharedpoint-ts can still be improved..
what about babel-ts?

You duplicated the Endpoint definition in this new repo, that's why you
don't have dependencies :)

hoo I see what you mean now, that's just a leftover there is nothing implemented yet (I just published the repo so that I could let you see the readme I was working about :D), when things will be finished there will be no Endopoint anywhere, just Commands and Queries 💣

cqrs-ts is not an "exotic" name, but more a boring-legacy name: what do
you think about sharedpoint-ts?
endpoint -> startpoint (cause in this case we "start" from the endpoint
definition) -> sharedpoint (one endpoint for all)

not bad you got a point, the idea is very cool but I think sharedpoint-ts can still be improved..
what about babel-ts?

or ido-ts https://en.wikipedia.org/wiki/Ido

or ido-ts https://en.wikipedia.org/wiki/Ido


Blank lines being inserted before/after  links from feed

This looks like a regression in NewsBlur to me. My guess is something that's extracting HTML from the Atom feed is inserting P tags that shouldn't be there.
These screenshots are from Chrome Version 32.0.1700.19 beta on Mac OS X 10.8.5. It looks identical in Firefox 25.0.1.
How it looks in NewsBlur

How it looks on my website

HTML from the feed
Note this is a good looking escaping. Blogger is what powers my site
<content type='html'>Compare the goals of <a href="http://www.cbsnews.com/news/amazon-unveils-futuristic-plan-delivery-by-drone/">Amazon's delivery drones</a> to Matternet for the developing world (<a href="http://www.fastcompany.com/1776951/matternet-flying-autonomous-delivery-system-developing-world">article from August 2011</a>):<br />
<br />
<iframe width="640" height="360" src="//www.youtube.com/embed/7B3E4OOuGDk?rel=0" frameborder="0" allowfullscreen></iframe></content>

Escaped HTML from the feed
Note there are no newlines
Compare the goals of Amazon's delivery drones to Matternet for the developing world (article from August 2011):

DOM that NewsBlur renders in my browser
Note the extra P tags

Compare the goals of
Amazon's delivery drones
 to Matternet for the developing world (
article from August 2011
):

Feed XML is here: http://www.onebigfluke.com/feeds/posts/default

This should be fixed by now.


Create a Crypto Collectibles Marketplace

Description:
We're entering the world of digital collectibles. Your task is to design a marketplace for buying and selling digital collectibles with a futuristic and crypto-inspired design.

Difficulty: intermediate
Estimated Time: 5-6 hours

Hi Jayesh,
Hi there! I'm interested in working on this issue. Could you please assign it to me? I believe I can make a valuable contribution to this task.
Looking forward to your response. Thanks!

Hello Sangita,
Thank you for your interest in working on this issue. I've assigned the issue to you, and you can now start working on it. If you have any questions or need any assistance, feel free to ask. Good luck with your contribution!
Best regards,
Jayesh


type is a child of bizTransaction/Source/Destination

Example picture needs to be adabted, as discussed

Adjusted both algorithm description as well as figures


Fix super slow iOS Tests

Updates dependencies to Nimble, Quick and SSZipArchive.
iOS Tests were running super slow (30 minutes total) this was because after every single test case the unzipped fixture repository would be deleted from disk and unzipped again from the 28MB big zip file. This was not an issue on Mac as unzip super fast (apparently) but SSZipArchive cannot quite keep up and so every single iOS test case would take 5-7 seconds to unzip + the time the test needs to run.
What I did is just unzip it once and store it in a directory called clean_repository, the directory is still removed after each test but instead of unzipping again I just copy the desired repository into its place not touching the clean_repository.

ITS GREEEN!!!!

Due to the Quick Update I had to set the deployment target of the Tests to iOS 9.0 which does not affect the framework itself.
A nice side effect of the Quick Update is that test names are now actually readable. :v:

This is amazingly faster. Nice work!
Had one snag when running carthage bootstrap:
A shell task failed with exit code 74:
xcodebuild: error: Unable to read project 'SSZipArchive.xcodeproj' from folder '/Users/phatblat/dev/libgit2/objective-git/Carthage/Checkouts/ZipArchive'.
	Reason: Project /Users/phatblat/dev/libgit2/objective-git/Carthage/Checkouts/ZipArchive/SSZipArchive.xcodeproj cannot be opened because it is missing its project.pbxproj file.

It looks like checking out the v1.0.1 tag left an empty SSZipArchive.xcodeproj folder since there is no project.pbxproj in the tree at that tag.
This was due to having an older ZipArchive checkout which left behind the .xcodeproj file and confused carthage and xcodebuild.

One little nitpick, there's now a dead workspace reference to the SSZipArchive project.

Yeah, SSZipArchive is a bit weird but we use the files directly.

Will remove the file reference.

Looks like v1.1 has framework targets now, but that can be updated in another PR.

Updated SSZipArchive v1.1 and fixed the reference.

Can't update to 1.1 because it has a lot of warnings. Staying on 1.0.1 but remove the reference to the project.

Sounds good to me!


how to reset password without login (Forget Password)?

how to reset the password from a front end
which URL to call API reset password

hello, there is an open issue to implement this https://github.com/joselfonseca/laravel-api/issues/78 I will work on it for V.11.0 which i hope is out in a few weeks. Right now you can implement that however you want.

hello, there is an open issue to implement this https://github.com/joselfonseca/laravel-api/issues/78 I will work on it for V.11.0 which i hope is out in a few weeks. Right now you can implement that however you want.


Text overlaps when boxes are too short

Release with the issue: v0.3.2
Description of problem:
When the value of a box is too low, there is not enough space to display the text, causing them to overlap with each other. Perhaps there should be an option to hide text if box height is less than a certain value?
(Thanks a lot again for the add-on! Sorry for sending so many issues in 😅)

I don't like hiding the text because you won't know what you are looking at unless it has a unique color. Might experiment with reducing font size or making that a config option.
Otherwise this behavior can be tweaked even now with min_box_height and min_box_distance options.

Maybe tooltip on mouseover? Smaller fonts for smaller items would work too.

Tooltip is a great idea in general. I use this on a read only mounted dashboard and haven't considered mouse actions much but it makes sense.

fixed in v0.4.1


auto_exposure: gstreamer 1.0 doesn't support exposure-min property

Commit 7e3838d45f1c80abd506ad6c599737b82ee20460 in the gstreamer-0.10 branch introduced the exposure-min property for auto_exposure. This property is missing in the gstreamer-1.0 implementation of auto_exposure.
Would it be possible to port this feature to the master branch?
Thanks & Regards,
Richard L.

You are right, this is a missing feature. We will port this feature to the master branch.

Ok. Thanks. Do you already know when it will be available?

Any updates/timeline on this issue?

The feature is currently being tested. You can expect the feature by next week.

Hi,
I pushed a preview branch:
https://github.com/TheImagingSource/tiscamera/tree/exposure-min
Can you try those changes and verify that everything works as you would expect?
After a few additional internal tests and your OK I would push them to master.

Introduced to master in ddf7bc3271beaaf8d711330f8a183876d62f1fe1. Thanks.


[Feature]: Remove time travel related code

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe.
Since 2.3.0 Milvus deprecatd time travel feature, we should remove it in rust sdk
Describe the solution you'd like.
No response
Describe an alternate solution.
No response
Anything else? (Additional Context)
No response

Hi @jiaoew1991, I would like to work on this issue. Can you please help me by pointing to the file which contains the code related to time travel.

hi @aniketh-varma you can search travel_timestamp in code, which should be removed

/assign @aniketh-varma

Hi @aniketh-varma I just checked, the time travel function has never been supported in Rust SDK, the 0 value set while querying/searching is informing the Milvus server to ignore this parameter.
We need to do nothing for this, so close it


Update oracle-database-network-plan.md

To fix typo Oracle.Database/networkAttachments

@jjaygbay1

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Home page collections

Decide on the collections, and choose a thumbnail image for each.
File a new issue for each collection to pin down its text.
(Layout of collection pages covered by #10.)

Selecting images covered by #41.


Add a projection onto L1 unit ball

Projection onto L1 unit ball is extremly useful for sparse solution. Quite surprising that is is not included in: optax/projections/_projections.py.
I would love to contribute it.

I actually need it for my work too and have implemented it in JAXopt so I will add it.

Fixed by 85378ad4ce1c19dfd218c65873f8941776c3eaca.


Refactor away multiple implementations of layer.name()

There's a bunch of different traits that have a function name() which retrieves the layer id. When importing all those traits, there's a name clash, which is not very ergonomic. Find some solution to this.

Has been fixed through a refactor to enums.


Update CONTRIBUTING.md

:tada: This PR is included in version 1.171.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Set value lov

Simple case, button with a dynamic action set value to lov.
Error

Workspace: mpgpi
User: demo
password: demodemo
page: lov

@michele-pauluzzi
its the minor bug. The case is that List of Values > Display Null Value > Null Return Value is not set.
Please download branch v1.1.1 which fix the issue and let me know about your test result.

This i fixed


Bypass virus scan by using new Google Drive API endpoint

This PR aims at fixing the Virus scan error and request for confirmation.
I have discovered that Google Drive changed the method of downloading endpoint from GET to POST, so I updated the code to fix that issue. Also, to pass the virus scan we just need to add a confirm="t" field to the URL, so I removed the code to read the token from the previous version.

This seems a duplicate of #28.
It may be better to crosscheck the existing activities to avoid double work


Lazload image items in tab

I have a problem where when i use the visible lazyload with tabs and switch to a different tab, the images doesnt load.

Confirmed: http://jsfiddle.net/enr5uonk/
When you remove the active class from the first tab and add that to the second tab, it works correctly.

Visibility does not work on content with display none until refresh.
Simple workaround
http://jsfiddle.net/enr5uonk/


[Fix][UI Next][V1.0.0-Alpha] Fix the default items display error in SQOOP.

Purpose of the pull request
This pull request fixs the default items display error in SQOOP.
Releated issues
close #9209

Codecov Report

Merging #9211 (9b0fe4d) into dev (8d60e92) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev    #9211      +/-   ##
============================================
- Coverage     40.20%   40.19%   -0.01%
+ Complexity     4375     4374       -1
============================================
  Files           817      817
  Lines         32686    32686
  Branches       3642     3642
============================================
- Hits          13140    13139       -1
- Misses        18316    18317       +1
  Partials       1230     1230

Impacted Files
Coverage Δ

...lphinscheduler/rpc/common/AbstractRpcCallBack.java
0.00% <0.00%> (-100.00%)
:arrow_down:

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 8d60e92...9b0fe4d. Read the comment docs.


bug: downloading private package tarball using axios fails

The current logic to fetch a tarball using axios doesn't provide any authentication information. This causes the fetch of private packages to fail with a 401 error code. https://github.com/banyudu/npm-migrate-all/blob/b954ef6280a37e7b651976bc0445a661037ce69a/src/index.ts#L202-L207
Instead, you can use npm pack to fetch the tarball. This uses the authentication information provided by your NPM configuration.
const downloadTarball = async (
  pkgName: string,
  version: string,
  registry: string
) => {
  const { stdout } = await $`npm pack ${getRegistryParam(pkgName, registry)} --pack-destination=${tempDir} ${pkgName}@${version}`
  return fs.readFileSync(path.join(tempDir, stdout.trim()))
}

Great, would you mind raising a PR for it?

I'm a bit short on time, but I will do my best to open a PR. My intention with opening the issues was to at least provide documentation in case someone runs into these issues 👍


Update to Express 4

IMPORTANT UPDATE!
Sails v1, will come with the latest version of Express4 even if this PR wasn't merged. Thanks to @sgress454 and @mikermcneil for all the hard work, and to all the people interested in this PR.
Joseba

Hi guys!
As you know Sails works with Express3 which is deprecated since August. I think that we've to move to v4 as soon as posible, so I've tried to help in this huge work.
I think that I have the 99% of the job done, but I need help doing more intensive testing to make sure that all works fine.
Check the migration guide
The changes that I've been forced to made:
HOOKS
Blueprints

Express 4 deprecated the req.param method in favor of req.params['param'] and req.query

Controllers

Indentation changes

Cors

A small fix to make sure that routeCorsConfig is always an object

CRSF

Removed connect dependency for CSURF, the official crsf express package

HTTP

That's one of the hooks with biggest changes, the router now works different, removing app.use(app.router); that.
Unbind works a little bit different, now is a little bit more complex but it's not a big deal.
The 404 and 500 errors are added to the router in a different place, we are force to it because of the new router. I add those two middlewares at the absolutely end. When sails triggers the ready event.
Now the session works with express-session package
The default middleware order changed removing 404 and 500 from here and adding csrf (in case that the csrf hook is activated)
Compression works with express compression package
FAVICON now is served with serve-favicon, and we are forced to add a default favicon in hooks/http/assets/favicon.ico, that's because the serve-favicon is forced to had a favicon, if it couldn't find one the app crashes.

Session

Again, removed connect session in favor of express-session.
Added a couple of defaults attributes

User Hooks

Indentation stuff

Views

That was hard, express4 doesn't work with layouts, so I've to add a layout support with a couple of functions inside the res.view method.

That in the hooks, now:
ROUTER

The same happens here, but the changes are really minimum.
In the default handlers we use the new sintaxis to send responses .status().send()
New way to unbind routes
cookie-parser & express-session packages added

Package.json

Added the latest express: 4.13.3
cookie-parser
csurf
express-session

TEST
I've to change some test to make them work with the new Express

The router test is updated, because of the router changes. Now to check if the routes are binded or unbinded we have to look inside the .stack object.
In the sample app controller the way to check route.key and route.method is updated to route.stack[0].method and route.stack[0].keys. I realized that the keys now works differently and we don't be able to get them always, I'm not sure why express does that

CORS and CRSF

In the CORS test, in the lines 64, 83 and 111 I can't get a 200 response code and I can't find why. That 3 tests are the only ones that don't work. I need some help there! And I can't get the HTTP METHODS complete list at 92 line. Those lines are commented right now.
Also, I've changed the sampleApp/views/viewTest/crsf.ejs file because it was wrong, we need to check if _crsf is null not if it is undefined, so I changed to the method: _.isNull(). Now it works like it should.
In the initializeHooks file, I removed supertest in favor of sails.request method, but the tests logic still as always and the same thing happen with the router.bind.test.js file.
In the router test file, I've added the .stack method
Unbind file with indentation changes

More or less that's all, I know that it's hard to make that kind of pull request work. But I would like to have some feedback about what do you guys have in mind for the express4 update.
 I'll review and get back to you.
I tried to work on this for a few hours and ended up in a hole I couldn't dig out of. I'm glad some people in the community are smarter than I am :)

We have to decide now whether we want to polyfill things like req.param() that a lot of current/older Sails apps likely rely on. Or if we want to hide behind semver as justification for breakage...

@mikermcneil @sgress454 @particlebanana any help in testing this would be appreciated.

I'm happy to help! The first thing we should fix is:
In the CORS test, in the lines 64, 83 and 111 I can't get a 200 response code and I can't find why. That 3 tests are the only ones that don't work. I need some help there! And I can't get the HTTP METHODS complete list at 92 line. Those lines are commented right now.
If we fix those three test, we'll have everything working.
Pd: I had to close and open the pull request to force Travis to run the test again

@Josebaseba Really appreciate your contributions to Sails and your dedication to the continued health of the project!  I also want to apologize for not getting involved sooner when you posted your original issue about migrating to Express 4.  Suffice it to say, we've been having a lot of discussion about this topic internally--specifically around how much Express should continue to be integrated into Sails core.
Something that's been on the roadmap for some time (admittedly, without much progress) is a plan for splitting much of the functionality currently provided by Express into separate modules.  In some ways, this PR is a step in that direction, since Express 4 already jettisoned most of the functionality into different packages.  But by simply upgrading all of our existing code to use those packages, we're still tying core to Express.  The real goal should be to pull that functionality--things like the views, session, and HTTP hooks--into completely separate modules.  If the first generation of those standalone hooks are Express 4-based, that's just fine with us.
What might be the best plan forward would be to take the work that's been done here, and use it to start fulfilling those items on the roadmap.  A great place to start would be a standalone views hook--something that can be installed as a replacement for the current core hook, like sails-hook-sockets does for the former core "sockets" hook.

@sgress454, so it will be with this PR?

Hi @sgress454,
I understand the goal of having all the hooks in separated npm modules, I think that it's really a good plan. But looking at the code, at least from my point of view, right now it's not close of being a reality.
And about being tied to express, what other options do you have in mind? Hapi, Koa, Connect... Your goal is keeping the http server into hooks.http.app and make it work with the rest of hooks in a agnostic way? That would be great but doing that all the hooks should change in a radical way, and the maintaining work would become really hard because of all the options and alternatives. Am I wrong?
More things, your intention is keeping Express3 and just make sure that there are not security issues? Don't you think that that can bring compatibility problems with new nodejs packages that only could work with express4? That could be a reason for making people not choosing Sails as a option for their projects, or if the new people that comes to Sails see the express3 dependency could think that the project is out of date...
I understand the fact that we don't need being updating all the packages because sometimes is not necessary, and only could bring problems. But I'm not sure if that's a good idea with the Express package.
Right now I see two options then, not updating to v4 and keep working in separating the hooks to external hooks trying to make the agnostic to everything and then choosing the http server. Or, try to update now to express4 and then keep working to arrive to that modular heaven.
I would like to have a little bit more information, and I'll be happy to help. At the end my business core is running Sails, so, we are in the same boat!
Pd: Sorry for my English! :-1:

@Josebaseba your English is great, no worries.  Bit of a crunch here today, but will get back to you on this ASAP.
To put it succinctly: Our main concern compatibility-wise with Sails is that it works with the latest stable version of Node (which...sigh).  As long as the version of Express we're using meets that standard, we're not that inclined to upgrade.
I understand the hesitation around splitting things into separate modules that need to be maintained--our experience with maintaining the core generator modules has been mixed, at best.  On the other hand, moving the sockets hook into sails-hook-sockets has been a real success, allowing for improvements and updates that don't require releasing a new version of Sails core.   I expect similar benefits from moving the other core hooks into separate modules.

More things, your intention is keeping Express3 and just make sure that there are not security issues?

Our eventual intention is to dump the core dependency on Express entirely.  Ideally, the only part of Express that Sails core should be using is the router, to implement _privateRouter.  If there were a standalone version of the Express 3 router, we would gladly use that.  Unfortunately there isn't, and Express 4's router has significant changes that you saw firsthand in your refactor--this is one of the main reasons we stalled on upgrading in the first place.  As far as security / compatibility issues, if all we're using from Express is the router, it's something we should be able handle--most of those issues come up in the middleware.
What does Sails look like without Express?  To the app developer, nothing would change, since there would be default modules installed for all of the former hooks (like sails-hook-sockets is for the former core sockets hook).  But under the hood, Sails would just be providing an interface for those hooks, instead of being responsible for their implementation.  For example, the interface for an HTTP hook would require it to handle the router:bind and router:unbind events from Sails, emit the hook:http:listening event when the server starts, and to allow the end-user to specify the middleware they wanted using sails.config.http.middleware.  But sails-hook-http-koa would use the Koa router and middleware instead of Express*, and Sails wouldn't know or care.  The core HTTP hook is already pretty close to being able to be removed, except for its entanglement with views.  That's why pulling out the views hook is a good place for us to start.
*this is by no means an easy thing to do, since Koa middleware are completely different from Express, but it would be pretty great for us to be engine-independent--and even if we only ever supported Express as an HTTP server, splitting it into a separate module would let us handle updates without having to patch core.

Thanks @sgress454 you've left me everything pretty clear. I just have a couple of questions more:

Why keep Express3 inside the private router if we can replace it for pillarjs router? I know that there are some changes to do (the biggest ones in unbind and reset methods) if we add the package but if I made it work you won't have any problem to make it too.

Are you going to manage all these changes internally? (Treeline / Balderdash team) Or the community could help there?

Thanks!

@Josebaseba :+1:

Why keep Express3 inside the private router if we can replace it for pillarjs router?

It's really just been a case of, "if it ain't broke, don't fix it".  Especially since we were still tied to Express for other things.  We're not opposed to changing the private router, ever, it just needs to be done super carefully.

Are you going to manage all these changes internally?

I frankly doubt it will happen at all without community help.  The basis of a standalone HTTP hook are here in this PR already.  The sticky wicket is the reliance of the views hook on Express's res.render functionality...

:+1:

@Josebaseba @sgress454 what's the status on this, and resolving some of the conflicts? I don't want this PR to go stale

@Josebaseba @mikermcneil any thoughts?

Ups @tjwebb , sorry for my late answer! I've been working hard these last weeks.
I didn't develop nothing new, I didn't want to work in a bad direction so I was waiting for more clues or some help to keep improving this pull request.
However few weeks ago I tried to separate the Views hook but I couldn't make it, the only way that I found was creating an own package for the res.view() method that express give us, but it's a little bit difficult. So much work that maybe goes nowhere.
I'll be glad to help if you need it, but for that I'll need the rules or steps that you think that will be the best ones to afford this challenge.

I think we should keep this PR focused on express 4, and we can merge in a views hook refactor into a subsequent PR. All we'd ask for here is just to resolve the merge conflicts. Apparently some updates to the hooks have been merged since this PR was submitted, and @Josebaseba you have the most expertise on how to reconcile these other changes with your updates.

Great, I'll do my best.

@Josebaseba awesome, thanks!

Hi @tjwebb, I've been working these days in this pull request, specifically in:

The pullRequest is up to date
Sessions are working now with latest version of connect-redis and connect-mongo (probably this new version will work with almost all the connect-* session adapters)
Some fixes in .ejs multiple layout support
A facade for the res.param('sth') method

To make a more detailed tests I run my own project with my express4 sails brach, the project it's a big one, +50 Controllers +40 Models, +200 routes etc, and all the tests are passing. It's working with Node 0.10, 0.12 and 4.2.0, I couldn't find any kind of problem. Waterline is working well to, with sails-mongo adapters v0.10.x and v0.11.x.
This project it's not using the sockets hook, so I run the sockets-hook tests against my sails brach and everything works fine too.
The only 3 tests that I couldn't be able to make them pass are:

CORS returning a 404 instead of 200
CORS 404 + Get the list of all the http methods
CORS 404 instead of 200 again

Obviously this pull request needs more test against real projects as I did with mine. But I think that we are really close to make it work :muscle:

@Josebaseba thank you for your hard work, it is nice to use express 4 in sails.

:+1:

@Josebaseba what's needed to get those remaining 3 tests passing? do you know?

+1

@tjwebb it has to be some kind of small detail into the CORS hook, I'm not familiarized with that hook so much but I'll try to find a solution or at least the reason these days.

Something broken in TravisCI? All the test are passing but it's saying that the checks have failed...

@tjwebb can you fix the tests?
jsinspect is finding a duplication but if you change the responses/defaults/created.js function name it'll work again:
module.exports = function sendOK (data, options) {

Change to:
module.exports = function sendCreated (data, options) {

Thanks!!

@Josebaseba Man, you are awesome. +1

I realized that the CORS hook it's working perfectly ok, but the default Express handler has change and that's the main reason that make the tests fail.
Those three or four assertions that are failing are expecting the old default handler response - a 200 status code + 'CHECKOUT,CONNECT,COPY,DELETE,GET,HEAD,LOCK,M-SEARCH,MERGE,MKACTIVITY,MKCOL,MOVE,NOTIFY,PATCH,POST,PROPFIND,PROPPATCH,PURGE,PUT,REPORT,SEARCH,SUBSCRIBE,TRACE,UNLOCK,UNSUBSCRIBE' response body. The rest of asserts, such as, 'access-control-allow-origin' 'access-control-allow-methods' 'access-control-allow-headers' etc... Are working perfectly.
I think that we should change a little those breaking assertions to adapt them to the Express4 logic and then start testing this fork against real world sails app, as I did with mine (and all went OK), to check if everything works as it should.
cc/ @tjwebb

Would like to see some more movement on this too. :)

@Josebaseba are these the assertions https://github.com/balderdashy/sails/pull/3322 you are talking about? seems like someone already made a PR for that fix

@moisesrodriguez yes and no, yes that's one of the assertion that changes with express4 and node4 but that pull request doesn't fix the express4 new behavior. The default handler that returns a 200 with all those http methods is not working on that way anymore. Or that's what I understand at least...
@niallobrien any help is welcome! :)

Hi @mikermcneil & @sgress454, reading this comment https://github.com/balderdashy/sails/issues/3460#issuecomment-169545356 I think that we can close this pull request. I'll keep the forked repo in my code just in case, could be interesting having it as a reference at some points.
I understand your next steps with Sails, moving to Express5 and making everything more modular, it'll be a hard work. But why not make this version update and then work in that way? And another question more, isn't it the Express5 development stopped?
Now here it comes my opinion about the last "events":
I'm really happy with Sails, it's the core of my business and after two years I still enjoying it, I never regret my choice. But thinking about the future of the framework and the community, and especially after this last month with Trails and all the posts about Sails dying, I think that you need to adapt/update the roadmap (it's being stopped for a long time) and make your move. These days you're been more active in the repos and that feels great, but maybe you need more active contributors that help you closing these roadmap features. Removing the old contributors that aren't working on it, and making some kind of a new start. As a heavy user of this framework I think that there're a lot of things to do.
I think that this project has the potential to become (for a long time) the best MVC framework. Trails is a good approach, but until the end of this year it'll be so immature, so Sails should use this time to show to the community that it still being a great option to make profesional and personal projects.
P.S: I really enjoyed making this PR, I've learn a lot about the internals and I'm pretty happy with the result. My intention was helping you guys to keep the project strong, no regrets!
P.S 2: I really DO like Trails  :+1:, and I'll keep an eye on it, but it's too young and it'll be for a while.

I really enjoyed making this PR, I've learn a lot about the internals and I'm pretty happy with the result. My intention was helping you guys to keep the project strong, no regrets!

@Josebaseba I really appreciate that, as well as all of your help over the years.
First of all, I'd like to apologize for the distracting, misleading, and ofttimes disrespectful dialogue carried out on our support channels and social media in recent weeks, as well as the confusion about Sails.  As I mentioned in the "Status of Sails" issue, in retrospect, it is clear our team should have publicly responded much earlier.  The fact that we didn't was my fault-- I actively suggested that we all stay silent and take the higher road.  Clearly that was a mistake that just made the situation worse.  Lesson learned.
For posterity: Cody, Scott, Rachael, Irl, and I have no beef with anyone doing a fork or rewrite of Sails or Waterline-- it has happened before, and it will happen again (and judging from my discussions with my friends and acquaintances who are other open-source maintainers, it's a part of everyday life as a project grows).
What made this situation so unfortunate is the misleading way in which the new project was presented.  That said, it seems like everyone is mostly clear on the facts now, which is great news.  I believe we should be using GitHub for discussion of a technical nature; so while I'm more than willing to enlighten anyone who feels they need to know the background of the "events", I do not plan to discuss it any further in a public setting.  As I've stated elsewhere, please don't hesitate to contact me directly if you have any questions.  I hope this allows us all to move on and get back to work.
Aside from everything else going on, it is clear we need a better line of communication between the user base as a whole, active contributors, and the Sails core team.  Part of the upcoming v0.12 release is a major rewrite of our contribution guide with the goal of refining the process, and introducing some ground rules that will make it easier to quickly respond to issues and pull requests without everyone having to feel guilty all the time.  I spent most of yesterday putting that together, and I'm looking forward to finishing it early this week, along with some new documentation about the myriad other ways Sails users can contribute back to the framework, including our approach for translating the documentation, supporting or starting a local Sails meetup group, and even supporting your local Node.js meetup group.  Yesterday, I also posted the first version of the Sails community's code of conduct, which I hope will help set up clear expectations for communication in GitHub and our other support channels in the future.

Sails should use this time to show to the community that it still being a great option to make profesional and personal projects.

Agreed.  I feel that much of the recent discussion has distracted everyone from what actually matters-- including the great work you've begun here, much of which is relevant and important in future development in Sails core.

isn't it the Express5 development stopped?

I'm not up to date with the latest enough to really provide any additional insight there, but I hope this helps explain why I feel that it is so important for Sails' long term strategy to use the underlying, federated modules in the jshttp and pillarjs projects.  I'm referring to that as "Express 5" just because that's the way it's been explained to me in the past.  I'd suggest bringing any other questions about that to Doug or any of the other guys who originally took over the Express project from TJ Hollawaychuk.  They are leading the charge there, doing great work, and I am 100% supportive of their efforts.  If you're interested in contributing to the bare metal of the Express project long term, Doug is the guy to talk to.
In the mean time, we're committed to taking ownership over fixing any major security, performance, or stability bugs that arise in Express 3.  If anyone reading this has doubts about our commitment to do so, please realize that our core team is running all of our own servers using the latest stable version of Sails in production (like always), and have every reason to make sure Sails and its dependencies are clean and well-oiled.
At the end of the day, what's best for everyone is to share as many trusted, high quality, well-tested dependencies as possible, and for those dependencies to become stable-- i.e. change as little as possible.  If frameworks like Sails, Express, Kraken, Connect, etc. can work together to share as many of those building blocks as possible, it will allow us to focus on the individualities which make each framework distinctly useful, instead of spending time reinventing the wheel.

@mikermcneil everything it's clear, thanks for your time!
As I told you I'm going to close this pull request but I'll keep the fork in my profile.
I'll keep around this project for a while so I'll try to keep contributing (maybe in more useful ways haha!) in the near future.

@mikermcneil Fantastic response. Love it, keep up the great work! :)

For the ones coming here, Express 4 will be default in Sails 1.0

@luislobo I'm gonna edit the first post to make It more clear

@Josebaseba @luislobo nice catch thanks guys

Good job! When can we expect 1.0 release with Express 4 support?